CN111783087A

CN111783087A - Method and device for detecting malicious execution of executable file, terminal and storage medium

Info

Publication number: CN111783087A
Application number: CN202010489587.2A
Authority: CN
Inventors: 陈勇; 李擎宇; 陈振明
Original assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Current assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Priority date: 2020-06-02
Filing date: 2020-06-02
Publication date: 2020-10-16

Abstract

The embodiment of the application discloses a method for detecting malicious execution of an executable file, which comprises the following steps: executing the executable file; detecting the behavior characteristics of the executable file in system calling; and under the condition that the behavior characteristics of the executable file meet preset conditions, determining that the executable file is a malicious file. The embodiment of the application also provides a detection device, a terminal and a storage medium for malicious execution of the executable file.

Description

Method and device for detecting malicious execution of executable file, terminal and storage medium

Technical Field

The present application relates to the field of electronic device technology, and relates to, but is not limited to, a method and an apparatus for detecting malicious execution of an executable file, a terminal, and a storage medium.

Background

With the increasing complexity of network environments, security threats facing more and more uncertain factors are increasing. Most of the current terminal security mechanisms only rely on Google and the platform security mechanisms, so that the terminal security mechanisms are easy to be cracked or bypassed by users with different interests, and a large number of executable files are subjected to high-risk operation or privilege giving but cannot be intercepted.

Disclosure of Invention

The embodiment of the application provides a method and a device for detecting malicious execution of an executable file, a terminal and a storage medium.

The technical scheme of the embodiment of the application is realized as follows:

in a first aspect, an embodiment of the present application provides a method for detecting malicious execution of an executable file, where the method includes:

executing the executable file;

detecting the behavior characteristics of the executable file in system calling;

and under the condition that the behavior characteristics of the executable file meet preset conditions, determining that the executable file is a malicious file.

In a second aspect, an embodiment of the present application provides an apparatus for detecting malicious execution of an executable file, including an execution module, a detection module, and a determination module, where:

the execution module is used for executing the executable file;

the detection module is used for detecting the behavior characteristics of the executable file in system calling;

the determining module is configured to determine that the executable file is a malicious file when the behavior feature satisfies a preset condition.

In a third aspect, an embodiment of the present application provides a terminal, including a memory and a processor, where the memory stores a computer program that is executable on the processor, and the processor implements the steps in the method for detecting malicious execution of an executable file when executing the program.

In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the steps in the method for detecting malicious execution of an executable file.

The beneficial effects brought by the technical scheme provided by the embodiment of the application at least comprise:

in the embodiment of the application, firstly, the executable file is executed; then, detecting the behavior characteristics of the executable file in system calling; finally, determining the executable file as a malicious file under the condition that the behavior characteristics meet preset conditions; therefore, the executable file is executed, the system call is triggered, and the detection logic is set in the system call, so that the executable file is accurately detected to be a malicious file, and the next operation is carried out.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, it is obvious that the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without inventive efforts, wherein:

fig. 1 is a schematic flowchart illustrating a method for detecting malicious execution of an executable file according to an embodiment of the present disclosure;

fig. 2 is a schematic flowchart illustrating another method for detecting malicious execution of an executable file according to an embodiment of the present disclosure;

fig. 3 is a schematic flowchart of a further method for detecting malicious execution of an executable file according to an embodiment of the present disclosure;

fig. 4 is a schematic flowchart of a further method for detecting malicious execution of an executable file according to an embodiment of the present disclosure;

FIG. 5 is a logic flow diagram of a method for detecting malicious execution of an executable file according to an embodiment of the present disclosure;

fig. 6A is a schematic structural diagram illustrating a composition of a detection apparatus for malicious execution of an executable file according to an embodiment of the present disclosure;

fig. 6B is a schematic structural diagram illustrating another apparatus for detecting malicious execution of an executable file according to an embodiment of the present disclosure;

fig. 7 is a schematic diagram of a hardware entity of a terminal according to an embodiment of the present disclosure.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some embodiments of the present application, but not all embodiments. The following examples are intended to illustrate the present application but are not intended to limit the scope of the present application. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

In the following description, reference is made to "some embodiments" which describe a subset of all possible embodiments, but it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict.

It should be noted that the terms "first \ second \ third" referred to in the embodiments of the present application are only used for distinguishing similar objects and do not represent a specific ordering for the objects, and it should be understood that "first \ second \ third" may be interchanged under specific ordering or sequence if allowed, so that the embodiments of the present application described herein can be implemented in other orders than illustrated or described herein.

It will be understood by those within the art that, unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which embodiments of the present application belong. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the prior art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

With the progress of society and the development of technology, people increasingly use mobile terminals to wirelessly access the internet to obtain information, including information browsing, file downloading, and the like. However, with the widespread of network information, the network security problem is becoming more serious, especially for many executable files, and not only can the current viruses and trojans steal password accounts to slow down the system, but also the viruses and trojans infect the executable files to delete the backup of ghost.

Due to the limitations of the hardware resources of the terminal itself, it is particularly necessary to download many executable files during the process of obtaining information or adding some additional functions to the access network, the security problem of the downloaded executable file is more serious, and nowadays, more and more terminal viruses or malicious programs are bundled or disguised as regular terminal application software to trick the user into downloading and installing, for example, the virus of mobile phone veterinarian spread widely by the name of mobile phone nurse and mobile phone housekeeping causes a great amount of calls among users, causes malicious situations that the users automatically send short messages, cannot unload the messages, steal user address books and the like through partial software installed in mobile terminals such as mobile phones and the like, the user has great potential safety hazard in the process of executing the executable file, and as the safety events are more and more frequently outbreak, the terminal safety problem gradually becomes the focus of industrial and even social attention.

The embodiment of the application provides a method for detecting malicious execution of an executable file, which is applied to a terminal. The terminal includes, but is not limited to, a mobile phone, a notebook computer, a tablet computer and a web-enabled device, a multimedia device, a streaming media device, a mobile internet device, a wearable device or other types of terminal devices. The functions implemented by the method can be implemented by calling program codes through a processor in the terminal, and the program codes can be stored in a computer storage medium.

Fig. 1 is a schematic flowchart of a method for detecting malicious execution of an executable file according to an embodiment of the present application, where as shown in fig. 1, the method at least includes the following steps:

step S110, executing the executable file.

Here, the executable file refers to a file that can be load-executed by the operating system.

For example, in different operating system environments, executable programs are presented differently. Under a Windows (Windows) operating system, the executable program may be a type of.exe file,. sys file,. com, etc. Under the Linux operating system, the file format of the Executable program is an Executable Linkable Format (ELF). The embodiments of the present application may be applicable to different operating systems, such as a Windows system, a Linux system, an android system, an apple iOS system, and the like, and the following embodiments are only described by taking the Linux system as an example.

Step S120, detecting the behavior feature of the executable file in the system call.

Here, the system call refers to a request from a program running in a user space to an operating system kernel for a service that requires higher authority to run. The system call provides an interface between the user program and the operating system (i.e., the system call is an interface for the user program to interact with the kernel).

Here, the behavior characteristic of the executable file includes at least one of: execution rights, execution path, execution context, and call state.

It should be noted that the executable file is called in the user space and trapped in the kernel space to execute the executable file through system call, and the execution state can be monitored in real time during the system call to detect whether the behavior characteristics of the executable file are normal.

Step S130, determining that the executable file is a malicious file when the behavior characteristics of the executable file meet a preset condition.

Here, the preset condition may be a judgment rule preset according to an execution characteristic of the malicious program. Whether the executable file is executed maliciously or not is detected in real time in the process of executing the executable file, so that the attack of a malicious program can be effectively prevented.

Fig. 2 is a schematic flowchart of another method for detecting malicious execution of an executable file according to an embodiment of the present disclosure, where as shown in fig. 2, the method at least includes the following steps:

step S210, running the executable file in the user space.

In an operating system, a virtual memory is usually divided into two blocks, i.e., a user space (userpace) and a Kernel space (Kernel space). The Linux operating system and the driver run in kernel space, and the application runs in user space.

Step S220, in the kernel space, the executable file is executed through the system call.

Here, the user may invoke a system call in its own application program through a system call command, the system call needs to be trapped in the kernel space from the user space, and the executable file is returned to the user space after the executable file is executed in the system call.

In the computer, a system call refers to a program running in a user space requesting a service requiring higher authority to run from an operating system kernel. The system call provides an interface between the user program and the operating system (i.e., the system call is an interface for the user program to interact with the kernel). The user program only runs in a user mode, sometimes needs to access the core function of the system, and uses the system call through the system call interface.

Step S230, setting an instrumentation function at a preset position in the system call.

Here, the instrumentation function is used to perform a detection process, typically a hook function (hook). The pile insertion is carried out at a proper position in the system calling, and the detection effect can be obtained.

Step S240, detecting the behavior characteristics of the executable file through the instrumentation function.

Here, by setting detection logic in the instrumentation function, the behavior characteristics of the executable file are detected and judged for further processing.

Step S250, determining that the executable file is a malicious file when the behavior characteristics of the executable file meet a preset condition.

In some possible embodiments, the behavior characteristic of the executable file includes an execution path and an execution permission, and the preset condition is that the execution path of the executable file is a preset path and the executable file does not have a root permission.

In some possible embodiments, the behavior characteristic of the executable file includes an execution path and an execution context, and the preset condition is that the execution path of the executable file is a preset path and the execution context is not secure.

In some possible embodiments, the behavior feature of the executable file includes an execution path and a call state, and the preset condition is that the execution path of the executable file is a preset path and the executable file is not called by a preset tool set.

In the embodiment of the application, the executable file is loaded into the memory space of the calling process through system calling, and the instrumentation function is set at the preset position of the system calling. And detecting the behavior characteristics of the executable file in real time in the process of executing the executable file by utilizing the instrumentation function. Therefore, whether the executable file is executed maliciously or not is determined by judging whether the behavior characteristics of the executable file meet the preset conditions or not, and the attack of a malicious program can be effectively prevented.

Fig. 3 is a schematic flowchart of another method for detecting malicious execution of an executable file according to an embodiment of the present application, where as shown in fig. 3, the method at least includes the following steps:

step S310, executing the executable file.

Step S320, detecting the behavior feature of the executable file in the system call.

Step S330, detecting whether the behavior characteristics of the executable file meet preset conditions or not under the condition that the terminal is unlocked.

Here, the terminal unlocking means that the security state of the terminal is an unlocked (unlocked) state, and the partial security mechanism is not detected any more after unlocking. If the terminal is unlocked, the behavior characteristics of the executable file are directly returned by skipping detection.

Step S340, determining that the executable file is a malicious file when the behavior characteristics of the executable file meet a preset condition.

Step S350, prohibiting the malicious file from being executed.

Here, the executable file is determined to be a malicious file, and then the executable file is intercepted, namely the malicious file is prohibited from continuing to execute. Meanwhile, the sample can be captured for subsequent analysis, such as automatically saving or copying the binary file of the malicious file to a preset position.

And step S360, reporting the interception event to an upper layer.

Here, after intercepting the malicious file, the interception event may be reported to an upper layer. Wherein, the information content contained in the interception event at least comprises one of the following: the process name or ID of the malicious file, the execution path of the malicious file, the execution authority of the malicious file and the like.

In the embodiment of the application, whether the terminal is unlocked or not is judged firstly after the system calling is started, and the behavior characteristics of the executable file are detected under the condition that the terminal is unlocked, so that the malicious execution of the executable file can be effectively detected. After the executable file is determined to be a malicious file, the process name/ID, the execution authority and the like of the malicious process are reported to an upper layer, so that the same executable file is prevented from being repeatedly detected or the malicious program is effectively intercepted.

Fig. 4 is a schematic flowchart of a method for detecting malicious execution of an executable file according to an embodiment of the present application, where behavior characteristics of the executable file at least include one of the following: execution rights, execution path, execution context, and call state. As shown in fig. 4, the step S130, the step S250, or the step S340 may be implemented by the following steps:

step S410, under the condition that the executable file has root authority, determining that the executable file is a malicious file.

Here, the root authority is one of system authorities, and is the highest authority of the entire system, and a super administrator user account in a general Linux system has the root authority, and can conveniently perform all operations of adding, deleting, modifying and checking on any file (including a system file) in the system.

It should be noted that, if it is determined that an executable file has root rights, which indicates that the executable file has participated in the privilege escalation operation and is destructive, the executable file may be determined to be a malicious file.

Step S420, determining that the executable file is a malicious file when the executable file does not have root permission, the execution path is a preset path, and the execution context is not safe.

Here, the preset path is an absolute path, and may be a path other than a preset protected path in the/data/directory. The preset protected path may be a code path reserved by *** compatibility test or a device manufacturer.

It should be noted that the data directory is established under the root directory of the operating system and used for storing user information and installed software. Because the authority under the/data/directory is high and the user can execute the program autonomously, most of malicious programs are hidden under the/data/directory. Therefore, by detecting the directory, the execution of the malicious program can be effectively intercepted.

Here, the execution context is a security context associated with the executable file, or a security context associated with a process executing the executable file. Where a security context refers to a class of permissions and rights that define what a process is allowed to do. Such as rights, privileges, access tokens, integrity levels, etc., may be included.

It should be noted that each process or service registers its own security context in the operating system, and if an executable file or an executing process has no security context, it indicates that the executable file is not registered in the operating system, and it is very likely to be a malicious program for a file whose way is unknown.

Step S430, under the condition that the executable file does not have root authority, the execution path is a preset path and the executable file is not called by a preset tool set, determining that the executable file is a malicious file.

Here, the preset tool set is an interface used by a terminal manufacturer in testing or function debugging, and has a specific authority. If the executable file is called by a preset tool set, the executable file is not detected; and if the executable file is not called by the preset tool set, determining that the executable file is a malicious file.

It should be noted that the execution order of the above steps S420 and S430 may be exchanged, and the step S430 may be executed selectively, and is only applicable to some terminals with specific rights reserved by specific manufacturers. The embodiments of the present application do not limit this.

In some possible embodiments, the executable file has a root authority, or the executable file does not have a root authority and the execution context is secure, the security event is reported to an upper layer.

In some possible embodiments, the security event is reported to an upper layer when the executable file does not have root authority and the executable file is called by a preset tool set.

Here, the information content included in the security event represents that the executable file has root rights and security context.

In some possible embodiments, the executable file is intercepted if the executable file does not have root rights and the execution context is not secure; and reporting the interception event to an upper layer.

In some possible embodiments, the executable file is intercepted if the executable file does not have root rights and the executable file is not a preset toolset call; and reporting the interception event to an upper layer.

Here, the information content included in the interception event includes at least one of: the process name or ID of the malicious file is executed, the execution path of the malicious file and the execution authority of the malicious file.

The following describes the method for detecting malicious execution of an executable file with reference to a specific embodiment, but it should be noted that this specific embodiment is only for better describing the present application and is not to be construed as a limitation to the present application.

In the mainstream android brand mobile phone technology at present, detection of malicious execution of an executable file can be self-developed. The existing scheme mostly limits the execution of malicious programs through a blacklist or whitelist mechanism, and detection logic has certain limitation. The android system is taken as an example in the embodiment of the application, whether the executable file is executed maliciously or not is detected in real time through system calling, and all executable files executed on the terminal can be detected.

Fig. 5 is a logic flow diagram of a method for detecting malicious execution of an executable file according to an embodiment of the present application, where as shown in fig. 5, the method at least includes the following steps:

in step S501, the executable file is executed.

Here, the executable file is executed in user space.

Step S502, calling a system call.

Here, after the executable file is executed in the user space, an executable (exec) system call is triggered to trap into the kernel layer.

It should be noted that the Linux provides a series of system calls exec, which can be used for running a new program, exec refers to a group of functions (total 6), and the exec function family is used for finding an executable file according to a specified file name and replacing the executable file with the executable file to be used for calling the content of the process, in other words, executing an executable file in the calling process.

The system calls in exec series all perform the same function, i.e. an executable program is loaded into the memory space of the calling process to change the execution code of the calling process, thereby forming a new process. If the exec call is successful, the calling process will be overridden and then executed from the entry of the executable program. That is, unlike the general case, the function of the exec function family is not returned after the function is successfully executed. Because the entity that called the process, including the code fragments, data fragments, and stack, etc., has been replaced with new content, only some apparent information, such as the process ID, remains intact. Only if the call fails will a-1 be returned, which is executed from the original program's call point and then down.

Step S503, detecting whether the terminal is unlocked.

Here, the state of the device lock may be detected (for example, if the android. verifiedboot indicates that the device lock is unlocked), and if the terminal is detected to be in the unlocked state, the detection process is exited; if it is detected that the terminal is not unlocked, step S504 is performed.

Step S504, whether the execution directory is in/data/down is detected.

Here, most of the malicious programs are in the/data directory, and the authority under the directory is high, so that the user can perform the malicious programs autonomously, detect the directory and effectively intercept the execution of the malicious programs. If the execution directory is detected not to be in/data/down, jumping out of the detection logic, and ending; if the execution directory is detected to be/data/down, the step S505 is executed to continue the detection

Step S505, check whether the execution directory is under/data/local/tmp/or not.

Here,/data/local/tmp/code path for *** compatibility test. If the execution directory is detected to be in/data/local/tmp/down, jumping out of the detection logic and ending; if it is detected that the execution directory is not/data/local/tmp/down, execution of step S506 continues with the detection.

It should be noted that what is actually detected in the process of executing step S504 is/data/other paths than/data/local/tmp/.

Step S506, detecting whether the executable file has root authority.

Here, if it is detected that the executable file has a root authority, that is, the executable file is executed by a root user, the detection logic is popped out, and step S510 is executed to report; if the execution directory is detected not to have root authority, the execution step S507 continues to detect.

Step S507, detecting whether the executable file has a security context.

Here, if the executable file is detected to have a security context, that is, the executed context environment is secure, the executable file jumps out of the detection logic, and step S510 is executed to report; if the execution directory is detected not to have root authority, the execution step S508 continues to detect.

In step S508, whether rutils exists is detected.

Here, rutils is a tool set for Java connection and using R language, and may be understood as an interface used by a terminal manufacturer in testing or function debugging, and has a specific authority. If the executable file is detected to have rutils call, jumping out of the detection logic, and ending; if it is detected that the executable file has no rutils call, step S509 is executed to intercept.

Step S509, intercepts malicious execution of the executable file.

Here, if the detection logic of steps S503 to S508 determines that the executable file executes maliciously, the executable file is prohibited from continuing to execute.

Here, in order to prevent an attack by a malicious program, it is generally necessary to control an application to be executed (i.e., an executable file) so as to prohibit execution of the malicious application. Specifically, the control of the application to be executed may be realized by a firewall, antivirus software, or the like.

Step S510, reporting the kernel event.

Here, the kernel event is an executable (execute) event. And reporting the EXECVE event to the upper application by calling a sending (send) function. The EXECVE event information represents what reason or what defect the malicious process is intercepted, and may include a process name, an ID, and a right the malicious process has.

According to the method for detecting the malicious execution of the executable file, the detection logic is inserted at the exec part of the system call, whether the executable file is executed maliciously or not can be judged through the execution path and the context environment, and meanwhile, the detected malicious program is intercepted and reported to the upper application.

Based on the foregoing embodiments, an embodiment of the present application further provides a device for detecting malicious execution of an executable file, where the control device includes modules and units included in the modules, and may be implemented by a processor in a terminal; of course, the implementation can also be realized through a specific logic circuit; in the implementation process, the Processor may be a Central Processing Unit (CPU), a microprocessor Unit (MPU), a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA), or the like.

Fig. 6A is a schematic structural diagram of a detection apparatus for malicious execution of an executable file according to an embodiment of the present application, and as shown in fig. 6A, the detection apparatus 600 includes an execution module 610, a detection module 620, and a determination module 630, where:

the execution module 610 is configured to execute the executable file;

the detecting module 620 is configured to detect a behavior feature of the executable file in a system call;

the determining module 630 is configured to determine that the executable file is a malicious file when the behavior feature satisfies a preset condition.

In some possible embodiments, the execution module 610 is configured to run the executable file in user space; and executing the executable file through the system call in a kernel space.

In some possible embodiments, the detection module 620 includes a setting sub-module and a detection sub-module, wherein: the setting submodule is used for setting a pile inserting function at a preset position in the system call; and the detection submodule is used for detecting the behavior characteristics of the executable file through the instrumentation function.

In some possible embodiments, as shown in fig. 6B, the detecting apparatus 600 further includes a prejudging module 640, configured to detect whether the behavior characteristic of the executable file meets a preset condition when the terminal is unlocked.

In some possible embodiments, the behavioral characteristics of the executable file include at least one of: the determining module 630 includes a first determining sub-module, a second determining sub-module, or a third determining sub-module, wherein: the first determining submodule is used for determining the executable file as a malicious file under the condition that the executable file has root authority; the second determining submodule is used for determining the executable file as a malicious file under the conditions that the executable file does not have root authority, the execution path is a preset path and the execution context is not safe; a third determining submodule, configured to determine that the executable file is a malicious file when the executable file does not have a root permission, the execution path is a preset path, and the executable file is not called by a preset tool set; the preset path is a path except for a preset protected path under the data/directory.

In some possible embodiments, as shown in fig. 6B, the detection apparatus 600 further includes an interception module 650 and a reporting module 660, where: the intercepting module 650 is configured to prohibit execution of the malicious file, and the reporting module 660 is configured to report an intercepting event to an upper layer; wherein, the information content contained in the interception event at least comprises one of the following: the process name or ID of the malicious file is executed, the execution path of the malicious file and the execution authority of the malicious file.

In some possible embodiments, the reporting module 660 is further configured to report a security event to an upper layer when the executable file has a root authority, or the executable file has a root authority and the execution context is secure; and the information content contained in the security event represents that the executable file has root authority and security context.

Here, it should be noted that: the above description of the apparatus embodiments, similar to the above description of the method embodiments, has similar beneficial effects as the method embodiments. For technical details not disclosed in the embodiments of the apparatus of the present application, reference is made to the description of the embodiments of the method of the present application for understanding.

It should be noted that, in the embodiment of the present application, if the detection method for malicious execution of an executable file is implemented in the form of a software functional module, and is sold or used as an independent product, the detection method may also be stored in a computer-readable storage medium. Based on such understanding, the technical solutions of the embodiments of the present application may be embodied in the form of a software product, where the computer software product is stored in a storage medium and includes several instructions to enable a terminal (which may be a smartphone with a camera, a tablet computer, or the like) to execute all or part of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read Only Memory (ROM), a magnetic disk, or an optical disk. Thus, embodiments of the present application are not limited to any specific combination of hardware and software.

Correspondingly, the present application provides a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the steps in the method for detecting malicious execution of an executable file according to any of the above embodiments.

Correspondingly, in an embodiment of the present application, a chip is further provided, where the chip includes a programmable logic circuit and/or a program instruction, and when the chip runs, the chip is configured to implement steps in the detection method for malicious execution of any executable file in the foregoing embodiments.

Correspondingly, in an embodiment of the present application, there is further provided a computer program product, which is used to implement the steps in the detection method for malicious execution of an executable file in any of the above embodiments when the computer program product is executed by a processor of a terminal.

Based on the same technical concept, embodiments of the present application provide a terminal, which is used to implement the method for detecting malicious execution of an executable file described in the foregoing method embodiments. Fig. 7 is a schematic diagram of a hardware entity of a terminal according to an embodiment of the present application, as shown in fig. 7, the terminal 700 includes a memory 710 and a processor 720, the memory 710 stores a computer program that can be executed on the processor 720, and the processor 720 executes the computer program to implement steps in any method for detecting malicious execution of an executable file according to an embodiment of the present application.

The Memory 710 is configured to store instructions and applications executable by the processor 720, and may also buffer data (e.g., image data, audio data, voice communication data, and video communication data) to be processed or already processed by the processor 720 and modules in the terminal, and may be implemented by a FLASH Memory (FLASH) or a Random Access Memory (RAM).

The steps of the session detection method of any of the above are implemented when the processor 720 executes a program. Processor 720 generally controls the overall operation of terminal 700.

The Processor may be at least one of an Application Specific Integrated Circuit (ASIC), a Digital Signal Processor (DSP), a Digital Signal Processing Device (DSPD), a Programmable Logic Device (PLD), a Field Programmable Gate Array (FPGA), a Central Processing Unit (CPU), a controller, a microcontroller, and a microprocessor. It is understood that the electronic device implementing the above-mentioned processor function may be other electronic devices, and the embodiments of the present application are not particularly limited.

The computer storage medium/Memory may be a Read Only Memory (ROM), a Programmable Read Only Memory (PROM), an Erasable Programmable Read Only Memory (EPROM), an Electrically Erasable Programmable Read Only Memory (EEPROM), a magnetic Random Access Memory (FRAM), a Flash Memory (Flash Memory), a magnetic surface Memory, an optical Disc, or a Compact Disc Read-Only Memory (CD-ROM), and the like; but may also be various terminals such as mobile phones, computers, tablet devices, personal digital assistants, etc., that include one or any combination of the above-mentioned memories.

Here, it should be noted that: the above description of the storage medium and device embodiments is similar to the description of the method embodiments above, with similar advantageous effects as the method embodiments. For technical details not disclosed in the embodiments of the storage medium and apparatus of the present application, reference is made to the description of the embodiments of the method of the present application for understanding.

It should be appreciated that reference throughout this specification to "one embodiment" or "an embodiment" means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present application. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. It should be understood that, in the various embodiments of the present application, the sequence numbers of the above-mentioned processes do not mean the execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application. The above-mentioned serial numbers of the embodiments of the present application are merely for description and do not represent the merits of the embodiments.

It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

In the several embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. The above-described device embodiments are merely illustrative, for example, the division of the unit is only a logical functional division, and there may be other division ways in actual implementation, such as: multiple units or components may be combined, or may be integrated into another system, or some features may be omitted, or not implemented. In addition, the coupling, direct coupling or communication connection between the components shown or discussed may be through some interfaces, and the indirect coupling or communication connection between the devices or units may be electrical, mechanical or other forms.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units; can be located in one place or distributed on a plurality of network units; some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiments of the present application.

In addition, all functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may be separately regarded as one unit, or two or more units may be integrated into one unit; the integrated unit can be realized in a form of hardware, or in a form of hardware plus a software functional unit.

Alternatively, the integrated units described above in the present application may be stored in a computer-readable storage medium if they are implemented in the form of software functional modules and sold or used as independent products. Based on such understanding, the technical solutions of the embodiments of the present application may be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for causing an automatic test line of a device to perform all or part of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a removable storage device, a ROM, a magnetic or optical disk, or other various media that can store program code.

The methods disclosed in the several method embodiments provided in the present application may be combined arbitrarily without conflict to obtain new method embodiments.

The features disclosed in the several method or apparatus embodiments provided in the present application may be combined arbitrarily, without conflict, to arrive at new method embodiments or apparatus embodiments.

The above description is only for the embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A method for detecting malicious execution of an executable file is applied to a terminal, and comprises the following steps:

executing the executable file;

2. The method of claim 1, wherein the executing the executable file comprises:

running the executable file in a user space;

and executing the executable file through the system call in a kernel space.

3. The method of claim 1, wherein detecting the behavioral characteristic of the executable file in the system call comprises:

setting a pile inserting function at a preset position in the system call;

and detecting the behavior characteristics of the executable file through the instrumentation function.

4. The method of claim 1, wherein the method further comprises:

and under the condition that the terminal is unlocked, detecting whether the behavior characteristics of the executable file meet preset conditions.

5. The method of claim 1, wherein the behavioral characteristics of the executable file include at least one of: execution authority, execution path, execution context and calling state; determining that the executable file is a malicious file under the condition that the behavior characteristics of the executable file meet a preset condition, wherein the determining comprises the following steps:

determining that the executable file is a malicious file under the condition that the executable file has root authority; or

Determining that the executable file is a malicious file under the conditions that the executable file does not have root authority, the execution path is a preset path and the execution context of the executable file is not safe; or

Determining that the executable file is a malicious file under the conditions that the executable file does not have root authority, the execution path is a preset path and the executable file is not called by a preset tool set;

the preset path is a path except for a preset protected path under the data/directory.

6. The method of claim 1 or 5, wherein the method further comprises:

prohibiting execution of the malicious file;

reporting an interception event to an upper layer; wherein the content of the first and second substances,

the information content contained in the interception event at least comprises one of the following: the process name or ID of the malicious file is executed, the execution path of the malicious file and the execution authority of the malicious file.

7. The method of claim 5, wherein the method further comprises:

reporting a security event to an upper layer under the condition that the executable file has root authority or the executable file does not have the root authority and the execution context is safe; wherein the content of the first and second substances,

the information content contained in the security event represents that the executable file has root authority and security context.

8. An apparatus for detecting malicious execution of an executable file, the apparatus comprising an execution module, a detection module, and a determination module, wherein:

the execution module is used for executing the executable file;

9. A terminal comprising a memory and a processor, the memory storing a computer program operable on the processor, wherein the processor when executing the program performs the steps of the method of any one of claims 1 to 7.

10. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the steps of the method of any one of claims 1 to 7.