Memory dump method and related equipment

Abstract

The embodiment of the invention provides a memory dump method and related equipment. The memory dump method comprises the following steps: monitoring a target process through a callback routine, and recording target memory information; scanning the recorded target memory, and determining whether a field of an executable file exists or not; if the field of the executable file exists, positioning and analyzing the corresponding executable file to obtain an analysis result; and if the analysis result is that the executable file needs to be dumped, dumping the executable file to the local. According to the technical scheme of the embodiment of the invention, the target process is monitored, the target memory information corresponding to the target process is recorded and analyzed, the executable file suspected to be related to the malicious code is determined, and the executable file is subjected to memory dump to be further analyzed, so that an effective security policy and a solution are formulated, and the security of the malicious code is improved. The problem that malicious codes are difficult to intercept by security software in the prior art is solved.

Description

Technical Field

[0001] The present application relates to the field of computer and communication technology, and in particular to a memory dump method and related equipment. Background Art

[0002] With the development of computers, fileless attacks and staged downloads have been increasingly used in network attacks. Today's malicious code will use a series of means such as encryption, obfuscation, staged downloads, and memory injection to prevent the Trojan files from being intercepted by security software. During the entire attack process, no malicious files are landed, making it difficult for security software to intercept. Summary of the invention

[0003] The embodiments of the present application provide a memory dump method and related devices, thereby overcoming the problem that the security software in the prior art is difficult to intercept malicious codes, at least to a certain extent.

[0004] Other features and advantages of the present application will become apparent from the following detailed description, or may be learned in part by the practice of the present application.

[0005] According to one aspect of an embodiment of the present application, a memory dump method is provided, comprising: monitoring a target process through a callback routine and recording target memory information; scanning the recorded target memory to determine whether there is a field for an executable file; if there is a field for the executable file, locating and parsing the corresponding executable file to obtain a parsing result; if the parsing result is that the executable file needs to be dumped, dumping the executable file locally.

[0006] In some embodiments of the present application, if the field of the executable file exists, the corresponding executable file is located and parsed to obtain a parsing result, which specifically includes: if the field of the executable file exists, the executable file is verified to determine whether the executable file is a valid executable file; if the executable file is a valid executable file and is not a dynamically linked file, it is determined that the parsing result is that the executable file needs to be dumped.

[0007] In some embodiments of the present application, if the field of the executable file exists, the executable file is verified to determine whether the executable file is a valid executable file, specifically including: if the field of the executable file exists, the header of the executable file is verified to determine whether the executable file has preliminary validity; if the executable file has preliminary validity, the entire executable file is verified to determine whether the executable file is valid.

[0008] In some embodiments of the present application, if the executable file has preliminary validity, the executable file as a whole is verified to determine whether the executable file is valid, specifically including: if the executable file has preliminary validity, determining whether the executable file is an expanded file; based on the result of whether the executable file is an expanded file, obtaining various identifiers and sizes of the executable file to determine whether the executable file is valid.

[0009] In some embodiments of the present application, if the executable file is a valid executable file and is not a dynamically linked file, determining the parsing result is that the executable file needs to be dumped, specifically includes: if the executable file is a valid executable file and is not a dynamically linked file, determining the parsing result according to whether the executable file is an expanded file; if the executable file is an expanded file, determining the parsing result is that the executable file needs to be dumped and needs to be reorganized; if the executable file is not an expanded file, determining the parsing result is that the executable file needs to be dumped and does not need to be reorganized.

[0010] In some embodiments of the present application, the scanning of the recorded target memory to determine whether there is a field for an executable file specifically includes: scanning the recorded target memory at predetermined intervals to determine whether there is a field for an executable file; in response to triggering a predetermined operation of the target process, scanning the corresponding target memory to determine whether there is a field for an executable file.

[0011] In some embodiments of the present application, the target process is monitored through a callback routine and the target memory information is recorded, which specifically includes: in response to the creation of the target process, the target process is monitored through a preset process control callback routine; all memory operations of the target process are intercepted through a preset hook function, and the target memory information is recorded.

[0012] In some embodiments of the present application, in response to the creation of the target process, the target is monitored through a preset process control callback routine, specifically including: in response to the creation of the target process, through a preset process control callback routine; hooking the target process with a preset hook function to monitor the target process through the preset hook function.

[0013] In some embodiments of the present application, intercepting all memory operations of the target process through a preset hook function and recording target memory information specifically includes: intercepting all memory operations of the target process through a preset hook function; in response to the success of memory allocation by the target process, obtaining properties of the target memory block; and recording the target memory information according to the properties of the target memory block.

[0014] According to one aspect of an embodiment of the present application, a memory dump device is provided, and the memory dump device includes: a process monitoring module, which is used to monitor the target process through a callback routine and record target memory information; a memory scanning module, which is used to scan the recorded target memory to determine whether there is a field for an executable file; a positioning and parsing module, which is used to locate and parse the corresponding executable file if the field for the executable file exists, and obtain a parsing result; and a file dump module, which is used to dump the executable file locally if the parsing result is that the executable file needs to be dumped.

[0015] In some embodiments of the present application, the positioning and parsing module specifically includes: a valid judgment submodule, which is used to verify the executable file if the field of the executable file exists, and determine whether the executable file is a valid executable file; a result determination submodule, which is used to determine that the parsing result is that the executable file needs to be dumped if the executable file is a valid executable file and is not a dynamically linked file.

[0016] In some embodiments of the present application, the validity judgment submodule specifically includes: a preliminary judgment unit, which is used to verify the header of the executable file if the field of the executable file exists, to determine whether the executable file has preliminary validity; an overall verification unit, which is used to verify the entire executable file if the executable file has preliminary validity, to determine whether the executable file has validity.

[0017] In some embodiments of the present application, the overall verification unit is specifically used to perform: if the executable file has preliminary validity, determine whether the executable file is an expanded file; based on the result of whether the executable file is an expanded file, obtain various identifiers and sizes of the executable file to determine whether the executable file is valid.

[0018] In some embodiments of the present application, the result determination submodule specifically includes: a result determination unit, which is used to determine the parsing result according to whether the executable file is an expanded file if the executable file is a valid executable file and not a dynamically linked file; a first determination unit, which is used to determine that the parsing result is that the executable file needs to be dumped and reorganized if the executable file is an expanded file; and a second determination unit, which is used to determine that the parsing result is that the executable file needs to be dumped and does not need to be reorganized if the executable file is not an expanded file.

[0019] In some embodiments of the present application, the memory scanning module specifically includes: a first scanning sub-module, used to scan the recorded target memory at predetermined intervals to determine whether there is a field for an executable file; a second scanning sub-module, used to scan the corresponding target memory in response to the triggering of a predetermined operation of the target process to determine whether there is a field for an executable file.

[0020] In some embodiments of the present application, the process monitoring module specifically includes: a process monitoring sub-module, which is used to monitor the target process through a preset process control callback routine in response to the creation of the target process; and an information recording sub-module, which is used to intercept all memory operations of the target process through a preset hook function and record target memory information.

[0021] In some embodiments of the present application, the process monitoring submodule specifically includes: a callback routine unit, which is used to respond to the creation of a target process through a preset process control callback routine; a hook function unit, which is used to hook the target process with a preset hook function to monitor the target process through the preset hook function.

[0022] In some embodiments of the present application, the information recording submodule specifically includes: an operation interception unit, used to intercept all memory operations of the target process through a preset hook function; an attribute acquisition unit, used to obtain the attributes of the target memory block in response to the success of the target process in allocating memory; an information recording unit, used to record the target memory information according to the attributes of the target memory block.

[0023] According to one aspect of an embodiment of the present application, a computer-readable medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the memory dump method as described in the above embodiment is implemented.

[0024] According to one aspect of an embodiment of the present application, an electronic device is provided, comprising: one or more processors; a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the memory dump method as described in the above embodiments.

[0025] In the technical solutions provided in some embodiments of the present application, the target process is monitored, its corresponding target memory information is recorded and analyzed, the executable file suspected to be related to the malicious code is determined, and its memory is dumped for further analysis, thereby gaining a deeper understanding of the characteristics and behavior of the malicious code, its attack methods and purposes, and thus formulating effective security strategies and solutions, overcoming the problem that security software in the prior art is difficult to intercept malicious code.

[0026] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] The drawings herein are incorporated into the specification and constitute a part of the specification, showing embodiments consistent with the present application, and together with the specification, are used to explain the principles of the present application. Obviously, the drawings described below are only some embodiments of the present application, and for ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work. In the drawings:

[0028] Figure 1 A schematic diagram of an exemplary system architecture to which the technical solution of the embodiments of the present application can be applied is shown.

[0029] Figure 2 A flow chart of a memory dump method provided in an embodiment of the present application is shown.

[0030] Figure 3 Shown according to Figure 2 A specific implementation flow chart of step S100 in the memory dump method shown in the corresponding embodiment.

[0031] Figure 4 Shown according to Figure 2 A specific implementation flow chart of step S300 in the memory dump method shown in the corresponding embodiment.

[0032] Figure 5 Shown according to Figure 4 A specific implementation flow chart of step S310 in the memory dump method shown in the corresponding embodiment.

[0033] Figure 6 Shown according to Figure 4 And a specific implementation flow chart of step S320 in the memory dump method shown in embodiment 5 corresponding to FIG.

[0034] Figure 7 A schematic structural diagram of a memory dump device provided in an embodiment of the present application is shown.

[0035] Figure 8 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0036] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in a variety of forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this application will be more comprehensive and complete and fully convey the concept of the example embodiments to those skilled in the art.

[0037] In addition, described feature, structure or characteristic can be combined in one or more embodiments in any suitable manner. In the following description, many specific details are provided to provide a full understanding of the embodiments of the present application. However, those skilled in the art will appreciate that the technical scheme of the present application can be put into practice without one or more of the specific details, or other methods, components, devices, steps, etc. can be adopted. In other cases, known methods, devices, realizations or operations are not shown or described in detail to avoid blurring the various aspects of the application.

[0038] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities may be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0039] The flowcharts shown in the accompanying drawings are only exemplary and do not necessarily include all the contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps can be decomposed, and some operations / steps can be combined or partially combined, so the actual execution order may change according to actual conditions.

[0040] Figure 1 A schematic diagram of an exemplary system architecture to which the technical solution of the embodiments of the present application can be applied is shown.

[0041] like Figure 1 As shown, the system architecture may include terminal devices (such as Figure 1 The embodiment of the present invention is a schematic diagram of a mobile phone 101, a tablet computer 102, a portable computer 103, a desktop computer, etc., a network 104, and a server 105. The network 104 is used to provide a medium for a communication link between the terminal device and the server 105. The network 104 may include various connection types, such as a wired communication link, a wireless communication link, etc.

[0042] It should be understood that Figure 1 The number of terminal devices, networks and servers in the embodiment is only for illustration. According to the implementation requirements, there may be any number of terminal devices, networks and servers. For example, the server 105 may be a server cluster composed of multiple servers.

[0043] The user can use the terminal device to interact with the server 105 through the network 104 to receive or send messages, etc. The server 105 can be a server that provides various services. For example, the user uses the terminal device 103 (or the terminal device 101 or 102) to upload the information of the target process to the server 105, and the server 105 can monitor the target process through the callback routine and record the target memory information; scan the recorded target memory to determine whether there is an executable file field; if there is an executable file field, locate and parse the corresponding executable file to obtain a parsing result; if the parsing result is that the executable file needs to be dumped, the executable file is dumped locally.

[0044] It should be noted that the memory dump method provided in the embodiment of the present application is generally executed by the server 105, and accordingly, the memory dump device is generally arranged in the server 105. However, in other embodiments of the present application, the terminal device may also have similar functions as the server, so as to execute the memory dump solution provided in the embodiment of the present application.

[0045] The implementation details of the technical solution of the embodiment of the present application are described in detail below:

[0046] Figure 2 A flowchart of a memory dump method according to an embodiment of the present application is shown. The memory dump method can be executed by a server, which can be Figure 1 The server shown in .

[0047] Reference Figure 2 As shown, the memory dump method at least includes:

[0048] Step S100, monitoring the target process through a callback routine and recording target memory information.

[0049] Step S200, scanning the recorded target memory to determine whether there is a field of an executable file.

[0050] Step S300: If the field of the executable file exists, locate and parse the corresponding executable file to obtain a parsing result.

[0051] Step S400: If the analysis result indicates that the executable file needs to be dumped, the executable file is dumped locally.

[0052] In an embodiment of the present application, by monitoring the target process, recording and analyzing its corresponding target memory information, determining the executable file suspected to be related to the malicious code, and performing a memory dump for further analysis, a deeper understanding of the characteristics and behavior of the malicious code, its attack method and purpose, and thus formulating effective security strategies and solutions, the problem that the security software of the prior art is difficult to intercept malicious code is overcome.

[0053] In step S100, whenever a new target process is created, the target process is added to the process record list of the callback routine for monitoring, and the corresponding memory information, i.e., target memory information, is recorded when the target process allocates memory. The memory information may include information such as the target memory address, memory length, and memory protection attributes.

[0054] Specifically, in some embodiments, the specific implementation of step S100 can be found in Figure 3 . Figure 3 is based on Figure 2 The detailed description of step S100 in the memory dump method shown in the corresponding embodiment, in the memory dump method, step S100 may include the following steps:

[0055] Step S110, in response to the creation of the target process, monitoring the target process through a preset process control callback routine.

[0056] Step S120, intercepting all memory operations of the target process through a preset hook function and recording target memory information.

[0057] In an embodiment of the present application, whenever a new target process is created, the new target process is added to the process record list for monitoring through a preset process control callback routine, all memory operations of the target process are intercepted through a preset hook function, and the target memory information is recorded to reflect memory changes.

[0058] In step S110, every time a target process is newly created, the newly created target process is added to the process record list for monitoring through a preset process control callback routine.

[0059] Specifically, in some embodiments, the specific implementation of step S110 can refer to the following embodiments. Figure 3 The detailed description of step S110 in the memory dump method shown in the corresponding embodiment, in the memory dump method, step S110 may include the following steps:

[0060] In response to the creation of the target process, a preset process control callback routine is passed.

[0061] The target process is hooked with a preset hook function to monitor the target process through the preset hook function.

[0062] In this embodiment, when a new target process is created, the created new target process is added to the process record list through the set process creation notification callback routine, and a memory tracking list is initialized for the target process to monitor the memory changes of the process. At the same time, the target process is hooked to a preset hook function to monitor the target process through the preset hook function.

[0063] That is, in the embodiment of the present application, a process creation notification callback routine is set in the operating system kernel to monitor the target process in the system, and the specified kernel API is hooked through the hook function. Among them, the operating system can be a mainstream operating system such as Windows operating system, Linux operating system, Mac operating system, etc.; the specified kernel API can include: NtAllocateVirtualMemory, NtFreeVirtualMemory, NtProtectVirtualMemory, NtMapViewOfSection, NtUnmapViewOfSection, NtCreateThread, NtCreateThreadEx, NtQueueApcThread, NtQueueApcThreadEx.

[0064] In some other embodiments of the application, when a new target process is created, the created target process is added to the process record linked list through the set process (i.e., the preset process) creation notification callback routine, and a memory tracking list is initialized for the target process to monitor the memory changes of the process. At the same time, the target process is hooked to a preset hook function to monitor the target process through the preset hook function. At the same time, after the target process is created, the image disk location and startup command line of the target process are obtained through the preset process creation callback routine. If the target process is rundll32.exe or regsvr32.exe, the target DLL loading location is recorded to match the target process image when the target process ends.

[0065] That is, in the above embodiment, a process creation notification callback routine is set in the operating system kernel to monitor the target process in the system, and the specified kernel API is hooked through the hook function. The operating system can be a mainstream operating system such as Windows operating system, Linux operating system, Mac operating system, etc.; the specified kernel API can include: NtTerminateProcess.

[0066] In the above embodiment, the specific method for matching the target process image includes:

[0067] When the target process ends, the target process Handle is obtained through the preset hook function mentioned above, and then the module loading address and the image local directory are obtained respectively, and the local image is loaded into the memory for comparison with the target process file. Specifically, the executable file header, section table header, NT header, optional header, entry address and context content of the executable file can be compared. If any of the above items does not match, it is determined that the executable file in the memory needs to be dumped locally to deal with behaviors such as self-extraction and process hollowing, and to increase the accuracy of detection.

[0068] In step S120, all memory operations of the target process are intercepted by a preset hook function, and target memory information is recorded to reflect memory changes.

[0069] Specifically, in some embodiments, the specific implementation of step S120 can refer to the following embodiments. Figure 3 The detailed description of step S120 in the memory dump method shown in the corresponding embodiment, in the memory dump method, step S120 may include the following steps:

[0070] All memory operations of the target process are intercepted through preset hook functions.

[0071] In response to the target process successfully allocating memory, the attributes of the target memory block are obtained.

[0072] According to the attributes of the target memory block, target memory information is recorded.

[0073] In this embodiment, any memory operation of the target process is intercepted by the set kernel API hook function, and the attributes of the target memory block are obtained after the target process successfully allocates memory. If the target memory block contains read-write attributes, copy-write attributes, execution attributes, read-write-execute attributes or copy-write-execute attributes, its allocated memory address, memory size, and memory protection attributes are added to the memory tracking list of the process to complete the recording of the target memory information.

[0074] In other embodiments, after the target process is created, when the target process starts a thread, the thread of the target process is also monitored, and the thread entry point is recorded to determine whether the thread entry point is located in any module in the monitoring process space. If the thread entry point is located in any module in the monitoring process space, the data of the specified length before and after the thread entry address is compared to see if they are consistent (that is, the memory data within the given length is compared to see if it is consistent with the local file.) If they are consistent, it means that the target process has been modified during execution, and the executable file in the memory needs to be dumped locally to deal with behaviors such as self-extraction and process hollowing, thereby increasing the accuracy of detection.

[0075] In step S200, when the target memory meets the preset conditions, a memory snapshot is created and the target memory is scanned to determine whether there is a field for an executable file. If there is a field for an executable file, it proves that the device may be attacked by malicious code.

[0076] Specifically, in some embodiments, the specific implementation of step S200 can refer to the following embodiments. Figure 2 The detailed description of step S200 in the memory dump method shown in the corresponding embodiment, in the memory dump method, step S200 may include the following steps:

[0077] At predetermined intervals, the recorded target memory is scanned to determine whether there is a field of an executable file.

[0078] In response to the triggering of a predetermined operation of the target process, the corresponding target memory is scanned to determine whether there is a field of an executable file.

[0079] In this embodiment, the preset condition that the target memory needs to meet may be every predetermined time, or the target process may execute a predetermined operation or need to execute a predetermined operation.

[0080] Specifically, when the memory protection attribute of the recorded target memory area is modified or memory mapped, a memory snapshot will be created and the corresponding target memory will be scanned after the corresponding operation is successful; when the recorded target memory area is about to be released or unmapped, a memory snapshot will be created and the corresponding target memory will be scanned before the operation is performed. After the scan is completed, the operation is performed again to remove the memory area from the memory tracking list; when the recorded target memory area is the starting address of a newly started thread or asynchronous procedure call, a memory snapshot will also be created and the corresponding target memory will be scanned, which usually involves process injection technology.

[0081] When the preset condition that the marked memory needs to meet may be that every predetermined time, a timed scanning thread may be created to periodically perform a quick scan on the recorded memory tracking list. The specific implementation method may refer to the following embodiment.

[0082] The value of a global variable is queried in a loop, and each time a value is assigned to the global variable, a specific scanning function is executed. That is, each time a target memory area needs to be scanned, its corresponding memory information is assigned to the global variable, thereby performing a scan. In this embodiment, the assignment adopts an atomic method (Interlocked Exchange Pointer) to ensure that only one place assigns a value to the global variable at the same time.

[0083] During scanning, the MD5 of the memory area information is calculated first. If it is already in the dump list, the memory area is skipped. Then it is attached to the target process, and the target memory data is read to determine whether it has a legal executable file header (PE Header) structure. When the executable file header feature field is scanned, it is determined that the executable file field exists, and then the next step is executed, and the pointer is moved within a certain range to try to verify the legitimacy of the executable file header.

[0084] In step S300, after the fields of the executable file are detected, a legality check is performed to confirm its validity. For valid executable files, dumping is required.

[0085] Specifically, in some embodiments, the specific implementation of step S300 can be found in Figure 4 . Figure 4 is based on Figure 2 The detailed description of step S300 in the memory dump method shown in the corresponding embodiment, in the memory dump method, step S300 may include the following steps:

[0086] Step S310: If the field of the executable file exists, the executable file is verified to determine whether the executable file is a valid executable file.

[0087] Step S320: If the executable file is a valid executable file and is not a dynamically linked file, it is determined that the parsing result is that the executable file needs to be dumped.

[0088] In this embodiment, the detected executable file is verified to determine the validity of the executable file. When the executable file is determined to be valid, if the valid executable file is not a low-value non-dynamically linked file, it is determined that the valid executable file needs to be dumped.

[0089] In step S310, the detected executable file is verified to determine the validity of the executable file.

[0090] Specifically, in some embodiments, the specific implementation of step S310 can be found in Figure 5 . Figure 5 is based on Figure 4 The detailed description of step S310 in the memory dump method shown in the corresponding embodiment, in the memory dump method, step S310 may include the following steps:

[0091] Step S312: If the field of the executable file exists, the header of the executable file is checked to determine whether the executable file has preliminary validity.

[0092] Step S314: If the executable file has preliminary validity, the entire executable file is verified to determine whether the executable file is valid.

[0093] In an embodiment of the present application, a validity check is first performed on the header of an executable file to check whether the executable file has a valid executable file structure, thereby determining whether it has preliminary validity. For executable files with preliminary validity, further in-depth verification is required to determine whether they have validity. For executable files without preliminary validity, they must not have validity. This embodiment preliminarily screens valid executable files by performing a validity check on the header of an executable file, and by relatively simply screening out a large number of executable files that are obviously invalid, thereby improving the efficiency of executable file validity detection.

[0094] In step S312, the legality check includes verifying the DOS header, NT header and section table information of the executable file. When all the checks confirm that a valid executable file structure is identified, step S314 is executed.

[0095] In step S314, when a valid executable file structure is identified through all verification confirmations, it is further determined based on its structure whether the executable file is an executable file that has been expanded in storage (ie, an expanded file), and then a validity check is performed.

[0096] Specifically, in some embodiments, the specific implementation of step S314 can refer to the following embodiments. Figure 5 The detailed description of step S314 in the memory dump method shown in the corresponding embodiment, in the memory dump method, step S314 may include the following steps:

[0097] If the executable file has preliminary validity, it is determined whether the executable file is an expanded file.

[0098] According to the result of whether the executable file is an expanded file, various identifiers and sizes of the executable file are obtained to determine whether the executable file is valid.

[0099] In this embodiment, if the executable file has preliminary validity, it is further determined whether the executable file is an expanded file based on its structure.

[0100] If it is not an expanded file, the executable file is obtained through physical address addressing, and the various identifiers and sizes of the executable file are checked normally to verify the validity of the executable file.

[0101] If it is an expanded file, the executable file is obtained through the virtual address method, and the various identifiers and sizes of the executable file are checked normally to verify the validity of the executable file.

[0102] In step S320, when it is determined that the executable file is valid, if the valid executable file is not a low-value non-dynamically linked file, it is determined that the valid executable file needs to be dumped.

[0103] Specifically, in some embodiments, the specific implementation of step S320 can be found in Figure 6 . and 6 are based on Figure 4 as well as Figure 5 The detailed description of step S320 in the memory dump method shown in the corresponding embodiment, in the memory dump method, step S320 may include the following steps:

[0104] Step S322: If the executable file is a valid executable file and is not a dynamically linked file, the parsing result is determined according to whether the executable file is an expanded file.

[0105] Step S324: If the executable file is an expanded file, it is determined that the parsing result indicates that the executable file needs to be dumped and reorganized.

[0106] Step S326: If the executable file is not an expanded file, it is determined that the analysis result is that the executable file needs to be dumped and does not need to be reorganized.

[0107] In this embodiment, after determining that the executable file is a valid executable file and not a dynamically linked file, further, if the executable file is not an expanded file, a memory snapshot containing the executable file is created, and the memory snapshot is dumped.

[0108] If the executable file is an expanded file, the structure is first repaired and corrected, and then the executable content is sequentially reorganized into a new executable file according to the executable file loading logic. After the reorganization is completed, the reorganized memory data is sent over the network, or the reorganized memory data is written to a local file and then the file is sent, thereby completing the dump.

[0109] In the above embodiment, if the executable file is an expanded file, the verification method for determining the validity of the executable file may specifically include: first locating the DOS header and NT header of the executable file, and if the corresponding identifier is incorrect, correcting the corresponding identifier and performing e_lfanew offset at the same time; secondly correcting the SizeOfHeader member in the optional header, and correcting the virtual addresses and sizes of the import function address table (IMAGE_DIRECTORY_ENTRY_IAT) and the bound import table (IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT) in the aforementioned optional header data directory, and initializing them to 0; then traversing the section table according to NumberOfSections and repairing the section table.

[0110] The specific traversal and repair methods may include: first verifying the validity of the section memory indicated by the section table, that is, the value of VirtualAddress+SizeOfRawData must not exceed the total size of the executable file (SizeOfImage); after the verification is passed, reassign VirtualAddress, Misc.VirtualSize, PointerToRawData, SizeOfRawData, and save the section detailed data and section data size for subsequent writing when rebuilding the executable file.

[0111] After the repair is completed, the repaired memory is copied to the new memory area in segments according to the executable file loading logic to reorganize the executable file, and a position is reserved in the new memory header to facilitate the subsequent storage of basic memory information, including memory address, memory size, target process body, and current context process body.

[0112] Finally, before dumping the target memory area, SSDeep will be used to calculate the similarity between the target memory area and other dumped memory areas. If the similarity is high, the dump will be skipped, thereby improving the accuracy of the memory dump.

[0113] In step S400, after the analysis result indicates that the executable file needs to be dumped, the executable file is dumped locally. If the executable file is not an expanded file, a memory snapshot containing the executable file is directly created, and the memory snapshot is dumped. If the executable file is an expanded file, its structure needs to be repaired and corrected first, and after the reorganization is completed, the reorganized memory data is sent through the network, or the reorganized memory data is written to a local file and then the file is sent, thereby completing the dump.

[0114] The following describes an apparatus embodiment of the present application, which can be used to execute the memory dump method in the above-mentioned embodiment of the present application. For details not disclosed in the apparatus embodiment of the present application, please refer to the above-mentioned embodiment of the memory dump method of the present application.

[0115] Figure 7 A block diagram of a memory dump device according to an embodiment of the present application is shown.

[0116] Reference Figure 7 As shown, a memory dump device 700 according to an embodiment of the present application includes:

[0117] The process monitoring module 710 is used to monitor the target process through a callback routine and record target memory information.

[0118] The memory scanning module 720 is used to scan the recorded target memory to determine whether there is a field of an executable file.

[0119] The positioning and parsing module 730 is used to locate and parse the corresponding executable file if the field of the executable file exists, and obtain the parsing result.

[0120] The file dump module 740 is configured to dump the executable file locally if the analysis result indicates that the executable file needs to be dumped.

[0121] In some embodiments of the present application, the positioning and parsing module specifically includes: a valid judgment submodule, which is used to verify the executable file if the field of the executable file exists, and determine whether the executable file is a valid executable file; a result determination submodule, which is used to determine that the parsing result is that the executable file needs to be dumped if the executable file is a valid executable file and is not a dynamically linked file.

[0122] In some embodiments of the present application, the validity judgment submodule specifically includes: a preliminary judgment unit, which is used to verify the header of the executable file if the field of the executable file exists, to determine whether the executable file has preliminary validity; an overall verification unit, which is used to verify the entire executable file if the executable file has preliminary validity, to determine whether the executable file has validity.

[0123] In some embodiments of the present application, the overall verification unit is specifically used to perform: if the executable file has preliminary validity, determine whether the executable file is an expanded file; based on the result of whether the executable file is an expanded file, obtain various identifiers and sizes of the executable file to determine whether the executable file is valid.

[0124] In some embodiments of the present application, the result determination submodule specifically includes: a result determination unit, which is used to determine the parsing result according to whether the executable file is an expanded file if the executable file is a valid executable file and not a dynamically linked file; a first determination unit, which is used to determine that the parsing result is that the executable file needs to be dumped and reorganized if the executable file is an expanded file; and a second determination unit, which is used to determine that the parsing result is that the executable file needs to be dumped and does not need to be reorganized if the executable file is not an expanded file.

[0125] In some embodiments of the present application, the memory scanning module specifically includes: a first scanning sub-module, used to scan the recorded target memory at predetermined intervals to determine whether there is a field for an executable file; a second scanning sub-module, used to scan the corresponding target memory in response to the triggering of a predetermined operation of the target process to determine whether there is a field for an executable file.

[0126] In some embodiments of the present application, the process monitoring module specifically includes: a process monitoring sub-module, which is used to monitor the target process through a preset process control callback routine in response to the creation of the target process; and an information recording sub-module, which is used to intercept all memory operations of the target process through a preset hook function and record target memory information.

[0127] In some embodiments of the present application, the process monitoring submodule specifically includes: a callback routine unit, which is used to respond to the creation of a target process through a preset process control callback routine; a hook function unit, which is used to hook the target process with a preset hook function to monitor the target process through the preset hook function.

[0128] In some embodiments of the present application, the information recording submodule specifically includes: an operation interception unit, used to intercept all memory operations of the target process through a preset hook function; an attribute acquisition unit, used to obtain the attributes of the target memory block in response to the success of the target process in allocating memory; an information recording unit, used to record the target memory information according to the attributes of the target memory block.

[0129] In an embodiment of the present application, by monitoring the target process, recording and analyzing its corresponding target memory information, determining the executable file suspected to be related to the malicious code, and performing a memory dump for further analysis, a deeper understanding of the characteristics and behavior of the malicious code, its attack method and purpose, and thus formulating effective security strategies and solutions, the problem that the security software of the prior art is difficult to intercept malicious code is overcome.

[0130] Figure 8A schematic diagram of the structure of a computer system suitable for implementing an electronic device of an embodiment of the present application is shown.

[0131] It should be noted that Figure 8 The computer system of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0132] like Figure 8 As shown, the computer system includes a central processing unit (CPU) 1801, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 1802 or the program loaded from the storage part 1808 to the random access memory (RAM) 1803, such as executing the method described in the above embodiment. In RAM 1803, various programs and data required for system operation are also stored. CPU 1801, ROM 1802 and RAM 1803 are connected to each other through bus 1804. Input / output (I / O) interface 1805 is also connected to bus 1804.

[0133] The following components are connected to the I / O interface 1805: an input section 1806 including a keyboard, a mouse, etc.; an output section 1807 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1808 including a hard disk, etc.; and a communication section 1809 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 1809 performs communication processing via a network such as the Internet. A drive 1810 is also connected to the I / O interface 1805 as needed. A removable medium 1811, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1810 as needed so that a computer program read therefrom is installed into the storage section 1808 as needed.

[0134] In particular, according to an embodiment of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a computer program for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication section 1809, and / or installed from a removable medium 1811. When the computer program is executed by a central processing unit (CPU) 1801, various functions defined in the system of the present application are executed.

[0135] It should be noted that the computer-readable medium shown in the embodiment of the present application may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, - but not limited to - an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by an instruction execution system, device or device or used in combination with it. In the present application, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, wherein a computer-readable computer program is carried. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which may send, propagate, or transmit programs for use by or in conjunction with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

[0136] The flowchart and block diagram in the accompanying drawings illustrate the possible architecture, functions and operations of the system, method and computer program product according to various embodiments of the present application. Wherein, each box in the flowchart or block diagram can represent a module, a program segment, or a part of the code, and the above-mentioned module, program segment, or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0137] The units involved in the embodiments described in this application may be implemented by software or hardware, and the units described may also be set in a processor. The names of these units do not, in some cases, constitute limitations on the units themselves.

[0138] As another aspect, the present application also provides a computer-readable medium, which may be included in the electronic device described in the above embodiment; or may exist independently without being assembled into the electronic device. The above computer-readable medium carries one or more programs, and when the above one or more programs are executed by an electronic device, the electronic device implements the method described in the above embodiment.

[0139] It should be noted that, although several modules or units of the equipment for action execution are mentioned in the above detailed description, this division is not mandatory. In fact, according to the embodiments of the present application, the features and functions of two or more modules or units described above can be embodied in one module or unit. On the contrary, the features and functions of one module or unit described above can be further divided into being embodied by multiple modules or units.

[0140] Through the description of the above implementation methods, it is easy for those skilled in the art to understand that the example implementation methods described here can be implemented by software or by combining software with necessary hardware. Therefore, the technical solution according to the implementation methods of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which can be a personal computer, a server, a touch terminal, or a network device, etc.) to execute the method according to the implementation methods of the present application.

[0141] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the embodiments disclosed herein. The present application is intended to cover any variations, uses or adaptations of the present application, which follow the general principles of the present application and include common knowledge or customary technical means in the art that are not disclosed in the present application.

[0142] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A memory dump method, characterized in that: include: Monitor the target process through the callback routine and record the target memory information; Scan the recorded target memory to determine whether there is a field of an executable file; If the field of the executable file exists, locate and parse the corresponding executable file to obtain a parsing result; If the analysis result indicates that the executable file needs to be dumped, the executable file is dumped locally.

2. The memory dump method according to claim 1, wherein: If the field of the executable file exists, the corresponding executable file is located and parsed to obtain the parsing result, which specifically includes: If the field of the executable file exists, verifying the executable file to determine whether the executable file is a valid executable file; If the executable file is a valid executable file and is not a dynamically linked file, it is determined that the parsing result is that the executable file needs to be dumped.

3. The memory dump method according to claim 2, characterized in that: If the field of the executable file exists, verifying the executable file to determine whether the executable file is a valid executable file specifically includes: If the field of the executable file exists, verifying the header of the executable file to determine whether the executable file has preliminary validity; If the executable file has preliminary validity, the entire executable file is verified to determine whether the executable file is valid.

4. The memory dump method according to claim 3, characterized in that: If the executable file has preliminary validity, verifying the entire executable file to determine whether the executable file is valid specifically includes: If the executable file has preliminary validity, determining whether the executable file is an expanded file; According to the result of whether the executable file is an expanded file, various identifiers and sizes of the executable file are obtained to determine whether the executable file is valid.

5. The memory dump method according to claim 2, wherein: If the executable file is a valid executable file and is not a dynamically linked file, determining that the parsing result is that the executable file needs to be dumped specifically includes: If the executable file is a valid executable file and is not a dynamically linked file, determining the parsing result according to whether the executable file is an expanded file; If the executable file is an expanded file, determining that the parsing result is that the executable file needs to be dumped and reorganized; If the executable file is not an expanded file, it is determined that the parsing result is that the executable file needs to be dumped and does not need to be reorganized.

6. The memory dump method according to claim 1, wherein: The scanning of the recorded target memory to determine whether there is a field of an executable file specifically includes: Scanning the recorded target memory at predetermined intervals to determine whether there is a field of an executable file; In response to the triggering of a predetermined operation of the target process, the corresponding target memory is scanned to determine whether there is a field of an executable file.

7. The memory dump method according to claim 1, characterized in that: The target process is monitored through the callback routine and the target memory information is recorded, specifically including: In response to the creation of the target process, monitoring the target process through a preset process control callback routine; All memory operations of the target process are intercepted through the preset hook function, and the target memory information is recorded.

8. A memory dump device, characterized in that: The memory dump device comprises: The process monitoring module is used to monitor the target process through the callback routine and record the target memory information; A memory scanning module, used to scan the recorded target memory to determine whether there is a field of an executable file; A positioning and parsing module, used for locating and parsing the corresponding executable file if the field of the executable file exists, and obtaining a parsing result; The file dump module is used to dump the executable file locally if the analysis result indicates that the executable file needs to be dumped.

9. A computer readable medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the memory dump method according to any one of claims 1 to 7 is implemented.

10. An electronic device, characterized in that: include: one or more processors; A storage device, used for storing one or more programs, when the one or more programs are executed by the one or more processors, enables the one or more processors to implement the memory dump method according to any one of claims 1 to 7.

Images