Method and system for identifying software behavior subject

Abstract

The present application provides a method for identifying the subject of software behavior, including: monitoring software behavior; performing stack backtracing on the current thread of the software behavior to obtain the target module file of the software behavior, wherein the target module file is a system module file that does not belong to the operating system; and identifying the real subject of the software behavior according to the import table of the target module file, wherein the import table of the target module file is used to store the function information imported by the target module file. The technical solution provided by the present application finds the target module file through stack backtracing, and further identifies the real subject initiating the software behavior through the import table of the target module file. The real subject of the software behavior can be used to perform further security detection on the software behavior, thereby improving the security protection of the software behavior.

Description

Technical Field

[0001] The present application relates to the field of information security technology, and in particular to a method, system, computer device and computer-readable storage medium for identifying software behavior subjects. Background Art

[0002] The behavior of a process can be loading system modules or private modules, or it can be initiated by a hacked third-party module. Most of the existing security protection based on software behavior is classified as the software behavior of the process body, which causes misjudgment of the behavior attribution for the behavior initiated by the hacked third-party module, thus letting go of the behavior of using the trusted process to do evil.

[0003] In view of the above-mentioned problems existing in the related technologies, it is necessary to provide a method for identifying the subject of software behavior, which can be used to perform further security detection on the software behavior and improve the security protection of the software behavior. Summary of the invention

[0004] The purpose of this application is to provide a method, system, computer device and computer-readable storage medium for identifying software behavior subjects, so as to solve the security protection problem of software behavior.

[0005] One aspect of an embodiment of the present application provides a method for identifying a subject of software behavior, characterized in that the method includes: monitoring software behavior; performing a stack backtrace on a current thread of the software behavior to obtain a target module file of the software behavior, wherein the target module file is a system module file that does not belong to the operating system; identifying a real subject of the software behavior based on an import table of the target module file, wherein the import table of the target module file is used to store function information imported by the target module file.

[0006] Optionally, performing a stack backtrace on the current thread of the software behavior to obtain a target module file of the software behavior includes: obtaining a system file list, the system file list including multiple system module files of the operating system; performing a backtrace on the function stack of the current thread to find a function call sequence of the software behavior; traversing the function call sequence to find a first non-system module file that does not belong to the system file list as the target module file.

[0007] Optionally, the function call sequence includes a module file to which at least one function called by the software behavior belongs.

[0008] Optionally, traversing the function call sequence to find the first non-system module file that does not belong to the system file list as the target module file includes: traversing the function call sequence from bottom to top, where from bottom to top refers to from the bottom to the top of the function stack; comparing the module files belonging to each layer of functions in the function call sequence with the multiple system module files in the system file list respectively; if the target module file belonging to the first target function from bottom to top in the function call sequence is different from each system module file in the system file list, then determining that the target module file is the first non-system module file that does not belong to the system file list.

[0009] Optionally, the system file list is a hash list, and the hash list includes a hash value of each system module file of the operating system.

[0010] Optionally, the comparing the module files belonging to each layer of functions in the function call sequence with the multiple system module files in the system file list respectively includes: calculating the hash value of the module files belonging to each layer of functions in the function call sequence; comparing the hash value of the module files belonging to each layer of functions with the hash value of each system module file in the system file list respectively; if the hash value of the target module file belonging to the first target function from bottom to top in the function call sequence is different from the hash value of each system module file in the system file list, then determining that the target module file is the first non-system module file that does not belong to the system file list.

[0011] Optionally, identifying the real subject of the software behavior based on the import table of the target module file includes: judging whether the lower-level function of the target function in the function call sequence is an API function exported by the operating system, the lower level refers to the next level from the top level of the function stack to the bottom level; if the lower-level function of the target function is not the API function, judging that the target module file is the real subject of the software behavior; if the lower-level function of the target function is the API function, judging whether the import table of the target module file imports the API function; if the import table of the target module file imports the API function, judging that the target module file is the real subject of the software behavior; if the import table of the target module file does import the API function, continuing to traverse the function call sequence.

[0012] One aspect of an embodiment of the present application provides a system for identifying the subject of software behavior, characterized in that it includes: a monitoring module for monitoring software behavior; an acquisition module for performing a stack backtrace on the current thread of the software behavior and acquiring a target module file, wherein the target module file is a system module file that does not belong to the operating system; an identification module for identifying the real subject of the software behavior based on an import table of the target module file, wherein the import table of the target module file is used to store function information imported by the target module file.

[0013] One aspect of an embodiment of the present application provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the method for identifying software behavior subjects as described above when executing the computer program.

[0014] One aspect of an embodiment of the present application provides a computer-readable storage medium, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the method for identifying software behavior subjects as described above when executing the computer program.

[0015] The method, system, computer device and computer-readable storage medium for identifying the subject of software behavior provided in the embodiments of the present application find the target module file (non-system module file) through stack backtracing traversal, and then further identify the real subject initiating the software behavior through the import table of the target module file (non-system module file). The found real subject of the software behavior can be used to perform further security detection on the software behavior, thereby improving the security protection of the software behavior. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 A flowchart of a method for identifying a software behavior subject according to Embodiment 1 of the present application is schematically shown;

[0017] Figure 2 for Figure 1 The sub-step diagram of step S102;

[0018] Figure 3 for Figure 2 Step S204 sub-step diagram;

[0019] Figure 4 for Figure 3 Sub-step diagram of step S302;

[0020] Figure 5 for Figure 1 The sub-step diagram of step S104;

[0021] Figure 6A specific example diagram of a method for identifying a software behavior subject is schematically shown;

[0022] Figure 7 A block diagram schematically shows a system for identifying software behavior subjects according to Embodiment 2 of the present application; and

[0023] Figure 8 The schematic diagram shows the hardware architecture of a computer device suitable for implementing the method for identifying software behavior subjects according to the third embodiment of the present application. DETAILED DESCRIPTION

[0024] In order to make the purpose, technical solutions and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present application.

[0025] It should be noted that the descriptions involving "first", "second", etc. in the embodiments of the present application are only for descriptive purposes and cannot be understood as indicating or implying their relative importance or implicitly indicating the number of technical features indicated. Therefore, the features defined as "first" and "second" may explicitly or implicitly include at least one of the features. In addition, the technical solutions between the various embodiments can be combined with each other, but they must be based on the ability of ordinary technicians in the field to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be deemed that such combination of technical solutions does not exist and is not within the scope of protection required by this application.

[0026] In the description of the present application, it should be understood that the numerical labels before the steps do not indicate the order in which the steps are executed, but are only used to facilitate the description of the present application and to distinguish each step, and therefore should not be understood as a limitation on the present application.

[0027] The following is an explanation of the terms involved in this application:

[0028] Memory, also known as internal storage and main memory, is used to load and run software, temporarily store processor computing data, etc.

[0029] API: It is the abbreviation of Application Programming Interface, which is the "interface between program and operating system" provided by the operating system to programmers.

[0030] API function: It is a predefined Windows function used to control the appearance and behavior of various components of Windows.

[0031] RVA: It is the abbreviation of Relative Virtual Address, which is a relative address or an offset.

[0032] Software behavior: It can refer to key behaviors on the execution path (e.g., required path) of malicious code attacks at the kernel layer, such as creating a process, opening a file, modifying the registry, loading a dynamic library, modifying memory, etc.

[0033] Thread: Software behavior can be executed through threads, and CPU resources and memory resources are scheduled on a thread basis.

[0034] Function call sequence: also called function call path, memory instruction sequence of a function, which may include the RVA of at least one function called by software behavior and its module file.

[0035] Function stack: refers to the area in the memory used to store function call information, including the function call sequence of software behavior.

[0036] From bottom to top, it means from the bottom to the top of the function stack.

[0037] Upward: refers to the direction from the bottom to the top of the function stack.

[0038] Lower layer: refers to the next layer from the top layer of the function stack to the bottom layer.

[0039] Stack backtrace: refers to the hierarchical relationship of function calls that is deduced upward.

[0040] System file list: may include multiple system module files of the operating system.

[0041] Target module file: It can refer to the system module file that does not come with the operating system, and can also be referred to as non-system module file.

[0042] Import table of target module file: used to store function information imported by the target module file.

[0043] HASH list: also called hash table, is a data structure that is directly accessed based on the key value.

[0044] PE file: PE is the abbreviation of Portable Executable. PE file can refer to a portable executable file, such as EXE and DLL. PE file can refer to a program file on Microsoft Windows operating system.

[0045] The present application aims to provide a solution for identifying the subject of software behavior, finding the target module file (non-system module file) through stack backtracing traversal; and further identifying the real subject initiating the software behavior through the import table of the target module file (non-system module file). The found real subject of the software behavior can be used to perform further security detection on the software behavior (for example: software permission check, local virus detection, cloud detection, etc.), thereby improving the security protection of the software behavior.

[0046] A number of embodiments will be provided below, and each of the embodiments provided below can be used to implement the solution of identifying the software behavior subject described above. For ease of understanding, the following exemplary description will be made with a computer device as the execution subject.

[0047] Embodiment 1

[0048] Figure 1 The flowchart of the method for identifying software behavior subjects according to the first embodiment of the present application is schematically shown.

[0049] like Figure 1 As shown, the method for identifying a software behavior subject in the first embodiment of the present application may include steps S100 to S104, wherein:

[0050] Step S100, monitoring software behavior.

[0051] As an example, a computer device can monitor the software behavior at the kernel layer, and the software behavior may refer to key behaviors on the execution path (e.g., necessary path) of malicious code attacks at the kernel layer, such as creating processes, opening files, modifying the registry, loading dynamic libraries, modifying memory, etc.

[0052] Step S102, performing stack backtracing on the current thread of the software behavior to obtain a target module file of the software behavior, wherein the target module file is a system module file that does not belong to the operating system.

[0053] As an example, the software behavior can be executed by threads, and CPU resources and memory resources are scheduled in units of threads. Assuming that the software behavior is to create a process, when the process creation behavior (software behavior) occurs on the computer device, the stack backtrace is performed on the current thread of the process creation.

[0054] As an example, Figure 2As shown, the step S102 may include steps S200 to S204. Among them: step S200, obtaining a system file list, the system file list includes multiple system module files of the operating system; step S202, backtracing the function stack of the current thread to find the function call sequence of the software behavior; step S204, traversing the function call sequence, and finding the first non-system module file that does not belong to the system file list as the target module file.

[0055] In an exemplary embodiment, the function call sequence includes a module file to which at least one function called by the software behavior belongs. Figure 3 As shown, the step S204 may include steps S300 to S304. Among them: step S300, traversing the function call sequence from bottom to top, the bottom to top may refer to the direction from the bottom to the top of the function stack; step S302, comparing the module files to which each layer of functions in the function call sequence belongs with the multiple system module files in the system file list; step S304, if the target module file to which the first target function from bottom to top in the function call sequence belongs is different from each system module file in the system file list, then determining that the target module file is the first non-system module file that does not belong to the system file list.

[0056] In an exemplary embodiment of the present application, the function call sequence is also referred to as a function call path, a memory instruction sequence of a function, and may include the RVA of at least one function called by the software behavior and the module file to which it belongs. For example, assuming that the software behavior calls function C, function B, and function A, the function call sequence may include: RVA1 of function C and the module file to which it belongs, RVA2 of function B and the module file to which it belongs, and RVA3 of function A and the module file to which it belongs. The modules to which RVA 1, RVA 2, and RVA3 belong may be the same module or different modules.

[0057] In an exemplary embodiment of the present application, the system file list may be a hash list (HASH list), and the hash list may include a hash value of each system module file of the operating system. Figure 4As shown, the step S302 may include steps S400 to S404. Among them: step S400, calculating the hash value of the module file to which each layer of function in the function call sequence belongs; step S402, comparing the hash value of the module file to which each layer of function belongs with the hash value of each system module file in the system file list; step S404, if the hash value of the target module file to which the first target function from bottom to top in the function call sequence belongs is different from the hash value of each system module file in the system file list, then determining that the target module file is the first non-system module file that does not belong to the system file list.

[0058] Please return to Figure 1 , step S104, identifying the real subject of the software behavior according to the import table of the target module file, the import table of the target module file is used to store the function information imported by the target module file.

[0059] As an example, Figure 5 As shown, Figure 1 The step S104 in the above may include steps S500 to S506. Among them: step S500, judging whether the lower layer function of the target function in the function call sequence is an API function exported by the operating system, the lower layer refers to the next layer from the top layer of the function stack to the bottom layer; if the lower layer function of the target function is not the API function, executing step S504, judging that the target module file is the real subject of the software behavior; if the lower layer function of the target function is the API function, executing step S502, judging whether the import table of the target module file imports the API function; if the import table of the target module file imports the API function, executing step S504, judging that the target module file is the real subject of the software behavior; if the import table of the target module file does not import the API function, executing step S506, continuing to traverse the function call sequence.

[0060] In an exemplary embodiment of the present application, the system module files of the Windows operating system (e.g., kernerl32.dll, ntdll.dll, etc.) export many functional API functions for users to call. The software behavior can be implemented by calling the API functions exported by the Windows operating system. For example, to implement the creation of a process (software behavior), the API functions exported by the Windows operating system that can be called include: WinExec\CreateProcess\CreateProcessInternal\CreateProcessAsUser\NtCreateUserProcess, etc., that is, one or more of these API functions can be called to implement the creation of a process.

[0061] In an exemplary embodiment of the present application, after the Windows operating system is started, a system file list L belonging to the Windows operating system can be obtained. When a software behavior occurs, the software behavior is intercepted at the kernel layer, and then the stack of the current thread of the software behavior is backtraced to obtain the function call sequence of the application layer (the function call sequence of the software behavior). For example, in the multi-level function call process, the processor (CPU) will push the next address of the calling function instruction into the stack, analyze the current stack frame, find the stack frame address of the upper function in the stack, and then analyze the stack frame of the upper function to find the stack frame address of the upper function... In this way, backtracking to the top-level function, thus forming a path track (calling sequence) of function execution, that is: the function call sequence of the application layer. After obtaining the function call sequence of the application layer (the function call sequence of the software behavior), traverse the function call sequence from bottom to top to find the first non-system module file A that does not belong to the system file list L, and then check whether there is an import of the lower-level API function in the import table of the non-system module file A. If there is an import of the lower-level API function, the non-system module file A is the real subject that initiates the software behavior.

[0062] like Figure 6 As shown, for ease of understanding, a specific example diagram of a method for identifying software behavior subjects is provided below.

[0063] Step S600: enumerate system module files after the operating system is started.

[0064] In an exemplary embodiment of the present application, the operating system may be a Windows operating system, the system module file may be a PE file, the PE file may be a portable executable file, for example: EXE and DLL are both PE files, and these PE files may be program files on the Microsoft Windows operating system.

[0065] Step S602, output the HASH list.

[0066] In an exemplary embodiment of the present application, the HASH list may include the hash value of each system module file of the Windows operating system. The hash value is a unique identifier of a file calculated using a hash algorithm. The hash values ​​of different files are different, and the influencing factors may be file size, content, creation date, etc.

[0067] Step S604, intercepting software behavior at the kernel layer.

[0068] As an example, the software behavior may refer to key behaviors on the kernel layer malicious code attack execution path (eg, necessary path), such as creating a process, opening a file, modifying the registry, loading a dynamic library, modifying memory, etc.

[0069] Step S606: perform stack backtracing on the current thread of the software behavior to obtain a function call sequence of the software behavior.

[0070] As an example, the software behavior can be executed by threads, and CPU resources and memory resources are scheduled in units of threads. Assuming that the software behavior is to create a process, when the process creation behavior (software behavior) occurs on the computer device, the stack backtrace is performed on the current thread of the process creation.

[0071] As an example, when a software behavior occurs, the software behavior is intercepted at the kernel layer, and then the stack of the current thread of the software behavior is backtraced to obtain the function call sequence of the application layer (the function call sequence of the software behavior). For example, in the multi-level function call process, the processor (CPU) will push the next address of the calling function instruction into the stack, analyze the current stack frame, find the stack frame address of the upper function in the stack, and then analyze the stack frame of the upper function to find the stack frame address of the upper function... and so on, backtracing to the top-level function, thus forming a path track (calling sequence) of function execution, that is: the function call sequence of the application layer (the function call sequence of the software behavior).

[0072] In an exemplary embodiment of the present application, the function call sequence may also be referred to as a function call path, a memory instruction sequence of a function, and may include the RVA of at least one function called by the software behavior and the module file to which it belongs. For example, assuming that the software behavior calls function Z, function Y, and function X, the function call sequence may include: RVA1 of function Z and the module file to which it belongs, RVA2 of function Y and the module file to which it belongs, and RVA3 of function X and the module file to which it belongs. The modules to which RVA 1, RVA 2, and RVA3 belong may be the same module or different modules.

[0073] Step S608, traversing each layer of functions in the function call sequence from bottom to top, where from bottom to top may refer to from the bottom layer to the top layer of the function stack.

[0074] Step S610, determining whether the module file to which each layer of functions in the function call sequence belongs is a non-system module file.

[0075] As an example, whether the module file to which each layer of function belongs is a non-system module file can specifically include: calculating the hash value of the module file to which each layer of function belongs; comparing the hash value of the module file to which each layer of function belongs with the hash value of each system module file in the HASH list respectively; if the hash value of the module file (target module file) to which a certain layer of function (target function) belongs is different from the hash value of each system module file in the HASH list, it can be determined that the module file (target module file) to which the function (target function) belongs is a non-system module file, and step S612 is continued; if the hash value of the module file to which a certain layer of function belongs is the same as the hash value of one of the multiple system module files in the HASH list, it can be determined that the module file to which the function belongs is a system module file, and the process returns to step S608.

[0076] Step S612, determining whether the lower layer function of the target function is an API function exported by the operating system, wherein the lower layer may refer to a layer from the top layer of the function stack to the bottom layer.

[0077] In an exemplary embodiment of the present application, the system module files of the Windows operating system (e.g., kernerl32.dll, ntdll.dll, etc.) can export many functional API functions for users to call. The software behavior can be implemented by calling the API functions exported by the Windows operating system. For example, to implement the creation of a process (software behavior), the API functions exported by the Windows operating system that can be called include: WinExec\CreateProcess\CreateProcessInternal\CreateProcessAsUser\NtCreateUserProcess, etc., that is, one or more of these API functions can be called to implement the creation of a process.

[0078] As an example, following the above example, assume that the software behavior calls function Z, function Y, and function X, the module file to which function Z belongs is a system module file, and the module file A to which function Y belongs is a non-system module file, then function Y is the target function, and the module file A to which function Y belongs is the target module file, and accordingly, the lower-level function of the target function Y is function Z. If the lower-level function Z of the target function Y is an API function exported by the operating system, continue to execute step S614; if the lower-level function Z of the target function Y is not an API function exported by the operating system, continue to execute step S616.

[0079] Step S614, determining whether the import table of the non-system module file A imports the API function.

[0080] As an example, if the import table of the non-system module file A imports the API function, step S616 is executed; if the import table of the non-system module file A does not import the API function, the process returns to step S608.

[0081] Step S616, outputting the non-system module file A as the real subject initiated by the software behavior.

[0082] Figure 6 Steps S608 to S606 may be executed in a loop until each layer of the function call sequence is traversed and completed, and the non-system module file A is output as the real subject initiated by the software behavior.

[0083] Embodiment 2

[0084] Figure 7 A block diagram of a system for identifying software behavior subjects according to Embodiment 2 of the present application is schematically shown. The system for identifying software behavior subjects can be divided into one or more program modules, and one or more program modules are stored in a storage medium and executed by one or more processors to complete the embodiment of the present application. The program module referred to in the embodiment of the present application refers to a series of computer program instruction segments that can perform specific functions. The following description will specifically introduce the functions of each program module in this embodiment.

[0085] like Figure 7 As shown, the system 700 for identifying software behavior entities may include a monitoring module 702 , an acquisition module 704 , and an identification module 706 .

[0086] The monitoring module 702 is used to monitor software behavior.

[0087] As an example, the monitoring module 702 is used to monitor the software behavior at the kernel layer, and the software behavior may refer to key behaviors on the execution path (e.g., necessary path) of malicious code attacks at the kernel layer, such as creating processes, opening files, modifying the registry, loading dynamic libraries, modifying memory, etc.

[0088] The acquisition module 704 is used to perform stack backtracing on the current thread of the software behavior and acquire the target module file of the software behavior, where the target module file is a system module file that does not belong to the operating system.

[0089] As an example, the software behavior can be executed by threads, and CPU resources and memory resources are scheduled in units of threads. Assuming that the software behavior is to create a process, when the process creation behavior (software behavior) occurs on the computer device, the acquisition module 704 is used to perform a stack backtrace on the current thread of the creation process.

[0090] As an example, the acquisition module 704 is also used to: obtain a system file list, which includes multiple system module files of the operating system; trace back the function stack of the current thread to find the function call sequence of the software behavior; traverse the function call sequence to find the first non-system module file that does not belong to the system file list as the target module file.

[0091] In an exemplary embodiment, the function call sequence includes a module file to which at least one function called by the software behavior belongs. As an example, the acquisition module 704 is also used to: traverse the function call sequence from bottom to top, and the bottom to top may refer to the direction from the bottom to the top of the function stack; compare the module file to which each layer of function in the function call sequence belongs with the multiple system module files in the system file list; if the target module file to which the first target function from bottom to top in the function call sequence belongs is different from each system module file in the system file list, then determine that the target module file is the first non-system module file that does not belong to the system file list.

[0092] In an exemplary embodiment of the present application, the system file list may be a hash list (HASH list), and the hash list may include the hash value of each system module file of the operating system. As an example, the acquisition module 704 is also used to calculate the hash value of the module file to which each layer of function in the function call sequence belongs; the hash value of the module file to which each layer of function belongs is compared with the hash value of each system module file in the system file list; if the hash value of the target module file to which the first target function from bottom to top in the function call sequence belongs is different from the hash value of each system module file in the system file list, it is determined that the target module file is the first non-system module file that does not belong to the system file list.

[0093] The identification module 706 is used to identify the real subject of the software behavior according to the import table of the target module file, and the import table of the target module file is used to store the function information imported by the target module file.

[0094] As an example, the identification module 706 is also used to: determine whether the lower-level function of the target function in the function call sequence is an API function exported by the operating system, where the lower level refers to the next level from the top level of the function stack to the bottom level; if the lower-level function of the target function is not the API function, then determine that the target module file is the real subject of the software behavior; if the lower-level function of the target function is the API function, then determine whether the import table of the target module file imports the API function; if the import table of the target module file imports the API function, then determine that the target module file is the real subject of the software behavior.

[0095] Embodiment 3

[0096] Figure 8 The schematic diagram of the hardware architecture of a computer device 1000 suitable for implementing the method for identifying software behavior subjects according to the third embodiment of the present application is schematically shown. In an exemplary embodiment of the present application, the computer device 1000 may be a device that can automatically perform numerical calculations and / or information processing according to pre-set or stored instructions. For example, it may be a smart phone, a tablet computer, a laptop computer, a desktop computer, a rack server, a blade server, a tower server or a cabinet server (including an independent server, or a server cluster composed of multiple servers), a gateway, etc. Figure 8 As shown, the computer device 1000 includes at least but is not limited to: a memory 1010, a processor 1020, and a network interface 1030 which can communicate with each other through a system bus. Among them:

[0097] The memory 1010 includes at least one type of computer-readable storage medium, and the readable storage medium includes a flash memory, a hard disk, a multimedia card, a card-type memory (e.g., an SD or DX memory, etc.), a random access memory (RAM), a static random access memory (SRAM), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a programmable read-only memory (PROM), a magnetic memory, a magnetic disk, an optical disk, etc. In some embodiments, the memory 1010 may be an internal storage module of the computer device 1000, such as a hard disk or a memory of the computer device 1000. In other embodiments, the memory 1010 may also be an external storage device of the computer device 1000, such as a plug-in hard disk equipped on the computer device 1000, a smart memory card (Smart Media Card, referred to as SMC), a secure digital (Secure Digital, referred to as SD) card, a flash card, etc. Of course, the memory 1010 may also include both the internal storage module of the computer device 1000 and its external storage device. In this embodiment, the memory 1010 is generally used to store the operating system and various application software installed in the computer device 1000, such as program code of the method for identifying the software behavior subject, etc. In addition, the memory 1010 can also be used to temporarily store various data that have been output or will be output.

[0098] In some embodiments, the processor 1020 may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip. The processor 1020 is generally used to control the overall operation of the computer device 1000, such as performing control and processing related to data interaction or communication with the computer device 1000. In this embodiment, the processor 1020 is used to run the program code stored in the memory 1010 or process data.

[0099] The network interface 1030 may include a wireless network interface or a wired network interface, and the network interface 1030 is generally used to establish a communication link between the computer device 1000 and other computer devices. For example, the network interface 1030 is used to connect the computer device 1000 to an external terminal through a network, and to establish a data transmission channel and a communication link between the computer device 1000 and the external terminal. The network may be a wireless or wired network such as an intranet, the Internet, the Global System of Mobile communication (GSM), Wideband Code Division Multiple Access (WCDMA), 4G network, 5G network, Bluetooth, Wi-Fi, etc.

[0100] It should be pointed out that Figure 8 Only a computer device having components 1010 - 1030 is shown, but it should be understood that implementing all of the components shown is not a requirement, and more or fewer components may alternatively be implemented.

[0101] In this embodiment, the method for identifying software behavior subjects stored in the memory 1010 can also be divided into one or more program modules and executed by one or more processors (processor 1020 in this embodiment) to complete the embodiment of the present application.

[0102] Embodiment 4

[0103] The present application also provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps of the method for identifying a software behavior subject in the embodiment are implemented.

[0104] In this embodiment, the computer-readable storage medium includes flash memory, hard disk, multimedia card, card-type memory (for example, SD or DX memory, etc.), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, disk, optical disk, etc. In some embodiments, the computer-readable storage medium can be an internal storage unit of a computer device, such as a hard disk or memory of the computer device. In other embodiments, the computer-readable storage medium can also be an external storage device of a computer device, such as a plug-in hard disk equipped on the computer device, a smart memory card (Smart Media Card, referred to as SMC), a secure digital (Secure Digital, referred to as SD) card, a flash card, etc. Of course, the computer-readable storage medium can also include both the internal storage unit of the computer device and its external storage device. In this embodiment, the computer-readable storage medium is generally used to store the operating system and various application software installed on the computer device, such as the program code of the method for identifying the software behavior subject in the embodiment. In addition, the computer-readable storage medium can also be used to temporarily store various types of data that have been output or are to be output.

[0105] Obviously, those skilled in the art should understand that the modules or steps of the above-mentioned embodiments of the present application can be implemented by a general computing device, they can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices, and optionally, they can be implemented by a program code executable by a computing device, so that they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be executed in a different order from that herein, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. In this way, the embodiments of the present application are not limited to any specific combination of hardware and software.

[0106] The above are only preferred embodiments of the present application, and are not intended to limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A method for identifying software behavior subjects, It is characterized in that The method comprises: Monitor software behavior; Perform stack backtracing on the current thread of the software behavior to obtain a target module file of the software behavior, where the target module file is a system module file that does not belong to the operating system; According to the import table of the target module file, identifying the real subject of the software behavior, the import table of the target module file is used to store the function information imported by the target module file; The step of performing stack backtracing on the current thread of the software behavior to obtain the target module file of the software behavior includes: Obtaining a system file list, wherein the system file list includes a plurality of system module files of an operating system; Backtracking the function stack of the current thread to find the function call sequence of the software behavior; Traversing the function call sequence, finding the first non-system module file that does not belong to the system file list as the target module file; The identifying the real subject of the software behavior according to the import table of the target module file includes: Determine whether a lower layer function of the target function in the function call sequence is an API function exported by the operating system, where the lower layer refers to a layer from the top layer of the function stack to the bottom layer; If the lower layer function of the target function is not the API function, then determining that the target module file is the real subject of the software behavior; If the lower layer function of the target function is the API function, determining whether the import table of the target module file imports the API function; If the import table of the target module file imports the API function, then the target module file is determined to be the real subject of the software behavior; If the import table of the target module file does not import the API function, continue to traverse the function call sequence.

2. The method for identifying software behavior subjects according to claim 1, It is characterized in that The function calling sequence includes a module file to which at least one function called by the software behavior belongs.

3. The method for identifying software behavior subjects according to claim 2, It is characterized in that The traversing the function call sequence to find the first non-system module file that does not belong to the system file list as the target module file includes: Traversing the function call sequence from bottom to top, where bottom to top means from the bottom to the top of the function stack; Compare the module files to which each layer of functions in the function call sequence belongs with the multiple system module files in the system file list respectively; If the target module file to which the first target function from bottom to top in the function call sequence belongs is different from each system module file in the system file list, it is determined that the target module file is the first non-system module file that does not belong to the system file list.

4. The method for identifying software behavior subjects according to claim 3, It is characterized in that The system file list is a hash list, and the hash list includes a hash value of each system module file of the operating system.

5. The method for identifying software behavior subjects according to claim 4, It is characterized in that The step of comparing the module files to which each layer of functions in the function call sequence belongs with the plurality of system module files in the system file list comprises: Calculate the hash value of the module file to which each layer of function in the function call sequence belongs; Compare the hash value of the module file to which each layer of function belongs with the hash value of each system module file in the system file list; If the hash value of the target module file to which the first target function from bottom to top in the function call sequence belongs is different from the hash value of each system module file in the system file list, it is determined that the target module file is the first non-system module file that does not belong to the system file list.

6. A system for identifying software behavior subjects, It is characterized in that include: Monitoring module, used to monitor software behavior; An acquisition module is used to perform stack backtracing on the current thread of the software behavior and acquire a target module file, wherein the target module file is a system module file that does not belong to the operating system; An identification module, used for identifying the real subject of the software behavior according to the import table of the target module file, wherein the import table of the target module file is used for storing function information imported by the target module file; The step of performing stack backtracing on the current thread of the software behavior to obtain the target module file of the software behavior includes: Obtaining a system file list, wherein the system file list includes a plurality of system module files of an operating system; Backtracking the function stack of the current thread to find the function call sequence of the software behavior; Traversing the function call sequence, finding the first non-system module file that does not belong to the system file list as the target module file; The identifying the real subject of the software behavior according to the import table of the target module file includes: Determine whether a lower layer function of the target function in the function call sequence is an API function exported by the operating system, where the lower layer refers to a layer from the top layer of the function stack to the bottom layer; If the lower layer function of the target function is not the API function, then determining that the target module file is the real subject of the software behavior; If the lower layer function of the target function is the API function, determining whether the import table of the target module file imports the API function; If the import table of the target module file imports the API function, then the target module file is determined to be the real subject of the software behavior; If the import table of the target module file does not import the API function, continue to traverse the function call sequence.

7. A computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, It is characterized in that When the processor executes the computer program, it is used to implement the steps of the method for identifying the software behavior subject described in any one of claims 1 to 5.

8. A computer-readable storage medium, It is characterized in that The computer-readable storage medium stores a computer program, which can be executed by at least one processor so that the at least one processor executes the steps of the method for identifying software behavior subjects described in any one of claims 1 to 5.

Images