CN117131497B

CN117131497B - Software detection method and electronic equipment

Info

Publication number: CN117131497B
Application number: CN202310233457.6A
Authority: CN
Inventors: 徐家运
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2023-02-28
Filing date: 2023-02-28
Publication date: 2024-06-14
Anticipated expiration: 2043-02-28
Also published as: CN117131497A

Abstract

The embodiment of the application provides a software detection method and electronic equipment, which are applied to the technical field of terminals. If the electronic equipment determines that the software to be detected comprises a plurality of target processes meeting the preset conditions, the electronic equipment detects that the software to be detected is the target software. The preset conditions comprise: any one of the plurality of target processes is in a waiting state for waiting to acquire a file lock held by a first process of the plurality of target processes, and the file lock held by any one of the plurality of target processes is also waiting to be acquired by a second process of the plurality of target processes, the first process being different from the second process. In the method, whether the software to be detected realizes the keep-alive of the process by a file lock reactivation mechanism is determined by whether a plurality of processes are mutually guarded in the software to be detected in the running process of the software to be detected, so that the software to be detected is detected to be target software.

Description

Software detection method and electronic equipment

Technical Field

The present application relates to the field of terminal technologies, and in particular, to a software detection method and an electronic device.

Background

Rogue software (badware) is becoming more prevalent in open network environments. Under the condition of not prompting and not passing through the permission of the user, rogue software is installed and operated on the electronic equipment of the user, and the rogue software has the characteristics of forced installation, difficult unloading, advertisement pop-up, malicious collection of user information and the like, and brings great inconvenience to the user.

In order to implement advertisement and information collection in the electronic equipment of the user for a long time as possible, rogue software can not only run a great deal of activities (such as playing silent music and continuously pulling up new components) in the background to improve the running priority of the rogue software, but also passively prevent the rogue software from being cleaned by a system of the electronic equipment as an idle process; but also to actively restart the process (or keep-alive process) after the process is shut down by the user. For the keep-alive behavior of rogue software, the current solution includes a dynamic detection method, i.e., the process of each software is turned off in turn to see if its keep-alive behavior is triggered. Thus, although rogue software with keep-alive behavior can be detected, normal use of the electronic device is affected.

Disclosure of Invention

Based on the above, the embodiment of the application provides a software detection method and electronic equipment, and the target software can be identified by detecting the keep-alive behavior of the software to be detected without closing the process of the software to be detected in the running process of the software to be detected, so that the normal use of the software to be detected is not influenced, and the user experience is good.

In a first aspect, the present application provides a software detection method, applied to an electronic device, where the electronic device runs software to be detected. In the running process of the software to be detected, if the software to be detected is determined to comprise a plurality of target processes meeting preset conditions, the electronic equipment detects that the software to be detected is the target software. The preset conditions include: any one of the plurality of target processes is in a waiting state for waiting to acquire a file lock held by a first process of the plurality of target processes, and the file lock held by any one of the plurality of target processes is also waiting to be acquired by a second process of the plurality of target processes, the first process being different from the second process.

The software to be detected comprises the following components: application software to be detected, system software to be detected and middleware to be detected. In the scheme, the electronic equipment starts and operates the software to be detected by starting the process of the software to be detected, so that all the processes of the software to be detected can be acquired in the process of operating the software to be detected. If multiple target processes exist in all the processes, the target processes are mutually daemon, that is, any process in the multiple target processes needs to daemon other processes, and also needs to daemon by other processes, it can be determined that the software to be detected adopts a file lock reviving mechanism, that is, the software to be detected can actively restart the process after the process is closed, so that the software itself is prevented from being closed, and therefore the software to be detected is determined to be the target software (or called rogue software). Because whether the processes in the software to be detected are mutually daemon or not is identified, and the processes of the software to be detected do not need to be closed, the software to be detected can be always operated in the detection process, normal service is provided for a user, and therefore user experience is better.

In this scheme, the first process daemon the second process, the first process is daemon by the third process, and the target process is described as including at least three processes. That is to say, under the condition that the number of mutually-daemon processes of the electronic equipment is more than 2, the software to be detected is determined to be the target software, so that the situation that normal software of the mutually-deadlock files caused by low code quality is misjudged to be the target software can be avoided, and the detection accuracy is improved.

In another possible design manner of the first aspect, the determining that the software to be detected includes a plurality of target processes that meet a preset condition includes: the electronic equipment acquires processes in the software to be detected, and each process with a file lock in the processes of the software to be detected corresponds to one node. For any process, if another process is in a waiting state for waiting for acquiring a file lock held by the process, the electronic device points a node corresponding to the other process to a node corresponding to the process, so as to obtain a directed edge indicating a waiting relationship between the two processes. Then, the electronic device deletes the node with the number of the directed edges pointing to other nodes being 0 and the node with the number of the directed edges pointing to other nodes being 0 in the nodes, and at least one directed ring is obtained. And then the electronic equipment determines the processes corresponding to the nodes in the directed ring with the number of the nodes being more than 2 as target processes.

In the design mode, in order to improve detection efficiency, the electronic device represents a process and a daemon with a directed graph, the process is used as a node of the directed graph, the daemon is used as an edge of the directed graph, whether a plurality of nodes form a directed ring or not is judged, and the number of the nodes in the directed ring is larger than 2, so that whether the software to be detected comprises a plurality of target processes meeting a first condition or not is determined. And if the software to be detected comprises a plurality of target processes meeting the first condition, the software to be detected is the target software. Otherwise, if no directed ring exists in the directed graph, or the number of nodes of any directed ring is smaller than or equal to 2, it is determined that the software to be detected does not include a plurality of target processes meeting the first condition, and the software to be detected is normal software, namely is not target software.

When inquiring whether the directed graph contains the directed ring, a depth-first search method can be adopted, specifically, a node (or vertex) of any non-isolated point in the directed graph is taken as a search starting point, depth-first search is carried out on the node, and when the node is searched again, the directed ring can be formed by the node and the directed edge involved in the current search path. The nodes related to the directed ring are the target processes, and the number of the nodes related to the directed ring is the number of the target processes.

In another possible design manner of the first aspect, the method further includes: the method comprises the steps that the electronic equipment obtains file lock information of software to be detected, wherein the file lock information is used for indicating that a process of the software to be detected holds a file lock or that the process of the software to be detected is in a waiting state of waiting for obtaining the file lock held by other processes. If the process holds the file lock or the process waits for the file lock to be acquired, the process corresponds to the file lock. If the same file lock corresponds to a plurality of processes according to the file lock information, the electronic device determines that one process of the plurality of processes is in a waiting state for waiting to acquire the file lock held by another process of the plurality of processes.

In the design mode, whether the file lock corresponds to a plurality of processes is determined through the file lock information of the software to be detected, if the file lock corresponds to the plurality of processes, the daemon relation of one process daemon to the other process exists in the plurality of processes is described, and the daemon relation can be determined according to whether the processes are in a waiting state or not. Specifically, the process is in a wait state, which indicates that the process is attempting to acquire a file lock held by another process, and the process does so in order to determine whether the other process is turned off by whether the process itself can acquire the file lock held by the other process. After the process is switched from the waiting state or the holding state, the process determines that the original process holding the file lock is closed, so that the original process is restarted to play a role of guarding the original process. That is, a process daemons for other processes by attempting to acquire their file locks, the daemons' relationships for the processes correspond to: a process attempting to acquire a file lock guards a process holding the file lock.

In another possible design manner of the first aspect, the obtaining file lock information of the software to be detected includes: the electronic equipment acquires process information of the software to be detected, wherein the process information comprises serial number information of the software to be detected and serial number information of a process. And then the electronic equipment acquires file lock information associated with the process according to the serial number information of the process, and acquires the file lock information associated with the process corresponding to the software to be detected according to the corresponding relation between the serial number information of the software to be detected and the serial number information of the process.

In the design mode, the file lock information of the software to be detected can be determined through the process information, specifically, a corresponding relation is formed between the software to be detected and the running process of the software to be detected, and the process information contained in the software to be detected is determined according to the number information of the corresponding process of the software to be detected. And determining file lock information associated with the process contained in the software to be detected based on the corresponding relation between the number information of each process in the process information contained in the software to be detected and the file lock information.

In another possible design of the first aspect, the file lock information includes number information of the file lock; the obtaining the file lock information associated with the process according to the number information of the process includes: if the number information of the file lock corresponds to the number information of the process and the number information of the file lock carries a waiting mark, determining that the file lock is waiting for acquisition by the process corresponding to the number information of the process; and acquiring the number information and the waiting identification of the file lock waiting to be acquired by the process. If the number information of the file lock corresponds to the number information of the process and the number information of the file lock does not carry the waiting mark, determining that the file lock is held by the process corresponding to the number information of the process; and acquiring the number information of the file lock held by the process.

In the design mode, different file locks are distinguished through the number information of the file locks, and the corresponding relation between the process and the file locks is distinguished through waiting for identification. If the number information of the file lock does not carry the waiting mark, the process corresponding to the number information of the file lock is indicated to hold the file lock; if the number information of the file lock carries a waiting identifier, the process corresponding to the number information of the file lock tries to hold the file lock, but because the file lock is held by other processes, the process is in a waiting state of waiting to acquire the file lock held by the other processes.

In another possible design manner of the first aspect, the number of the plurality of target processes is N, N is greater than 2, and N is an integer. Under the condition that N target processes are arranged based on file lock waiting relations, an ith target process in the N target processes is in a waiting state for waiting to acquire the file lock held by the (i+1) th target process in the N target processes, and the Nth target process in the N target processes is in a waiting state for waiting to acquire the file lock held by the (1) st target process in the N target processes, wherein i is less than N-1, and i is an integer greater than 0.

In the design mode, N target processes are arranged based on a file lock waiting relationship, namely the N target processes are divided into 1 st target processes according to arrangement sequence numbers, and the 2 nd target processes … th target processes are N target processes. These target processes form a head-to-tail daemon relationship, namely, the 1 st target process daemon, the 2 nd target process …, the N-1 st target process daemon, the N-th target process daemon, the 1 st target process. Thus, the head-to-tail daemon enables any process to be monitored by at least one process after being shut down, and then the process can be restarted so that the software to be detected continues to run.

In another possible design manner of the first aspect, the determining that the software to be detected includes a plurality of target processes that meet a preset condition includes: and determining that the software to be detected comprises at least two groups of a plurality of target processes meeting preset conditions.

In the design mode, under the condition that the number of directed rings forming the daemon relationship is larger than 1, the software to be detected is identified as target software. That is, only the software to be detected, which includes a plurality of pairs of processes in a directed ring daemon relationship and the number of processes in each pair of processes is greater than 2, is used as the rogue software, so that the probability of misjudging normal software as the rogue software is reduced, and the detection accuracy is improved.

In another possible design manner of the first aspect, the method further includes: and if the software to be detected does not comprise a plurality of target processes meeting the preset conditions, detecting that the software to be detected is not the target software.

In this design, normal software, i.e., software that is not the target software, can be identified. The method and the device are used for detecting the software to be detected in the running process of the software to be detected, and the process of the software to be detected is not closed, so that the normal use of the software is not affected under the condition that the software to be detected is normal, and the user experience is good.

In a second aspect, the present application provides an electronic device comprising: a processor, a memory for storing processor-executable instructions, the processor being configured to cause an electronic device to implement a method as described in the first aspect and any one of its possible designs.

In a third aspect, embodiments of the present application provide an electronic device, a memory and one or more processors, the memory coupled to the processors; wherein the memory has stored therein computer program code comprising computer instructions which, when executed by the processor, cause the processor to perform the steps of: the processor runs the software to be detected. In the running process of the software to be detected, if the software to be detected is determined to comprise a plurality of target processes meeting preset conditions, the processor detects that the software to be detected is the target software. The preset conditions include: any one of the plurality of target processes is in a waiting state for waiting to acquire a file lock held by a first process of the plurality of target processes, and the file lock held by any one of the plurality of target processes is also waiting to be acquired by a second process of the plurality of target processes, the first process being different from the second process.

In one possible design of the third aspect, the computer instructions, when executed by the processor, cause the processor to further perform the steps of: the processor acquires processes in the software to be detected, and each process with a file lock in the processes of the software to be detected corresponds to one node. For any process, if another process is in a waiting state for waiting to acquire the file lock held by the process, the processor points the node corresponding to the other process to the node corresponding to the process, and a directed edge indicating the waiting relationship between the two processes is obtained. The processor then deletes the node of the node having 0 directed edges to other nodes and the node having 0 directed edges to other nodes, resulting in at least one directed ring. The processor then determines the process corresponding to the node in the directed ring having a number of nodes greater than 2 as the target process.

In one possible design of the third aspect, the computer instructions, when executed by the processor, cause the processor to further perform the steps of: the processor acquires file lock information of the software to be detected, wherein the file lock information is used for indicating that a process of the software to be detected holds a file lock or that the process of the software to be detected is in a waiting state for waiting to acquire the file lock held by other processes. If the process holds the file lock or the process waits for the file lock to be acquired, the process corresponds to the file lock. If the same file lock corresponds to a plurality of processes according to the file lock information, the processor determines that one process of the plurality of processes is in a waiting state for waiting to acquire the file lock held by another process of the plurality of processes.

In one possible design of the third aspect, the computer instructions, when executed by the processor, cause the processor to further perform the steps of: the processor acquires process information of the software to be detected, wherein the process information comprises serial number information of the software to be detected and serial number information of a process. And then the processor acquires file lock information associated with the process according to the serial number information of the process, and acquires the file lock information associated with the process corresponding to the software to be detected according to the corresponding relation between the serial number information of the software to be detected and the serial number information of the process.

In one possible design of the third aspect, the computer instructions, when executed by the processor, cause the processor to further perform the steps of: if the number information of the file lock corresponds to the number information of the process and the number information of the file lock carries a waiting mark, the processor determines that the file lock is waiting for acquisition by the process corresponding to the number information of the process; the processor acquires the number information and the waiting identification of the file lock which is waited to be acquired by the process. If the number information of the file lock corresponds to the number information of the process and the number information of the file lock does not carry the waiting mark, the processor determines that the file lock is held by the process corresponding to the number information of the process; and acquiring the number information of the file lock held by the process.

In one possible design of the third aspect, the computer instructions, when executed by the processor, cause the processor to further perform the steps of: the processor determines that the software to be detected comprises at least two groups of a plurality of target processes meeting preset conditions.

In one possible design of the third aspect, the computer instructions, when executed by the processor, cause the processor to further perform the steps of: and if the software to be detected does not comprise a plurality of target processes meeting the preset conditions, the processor detects that the software to be detected is not the target software.

In a fourth aspect, the present application provides a computer readable storage medium comprising computer instructions which, when run on an electronic device, cause the electronic device to perform a method as described in the first aspect and any one of its possible designs.

In a fifth aspect, the present application provides a computer program product which, when run on a computer, causes the computer to perform the method according to the first aspect and any one of its possible designs.

It may be appreciated that the electronic device according to the second aspect, the electronic device according to the third aspect and any of the possible designs thereof, the computer readable storage medium according to the fourth aspect, and the computer program product according to the fifth aspect may refer to the advantages of the first aspect and any of the possible designs thereof, and are not described herein.

Drawings

FIG. 1 is a schematic diagram of a rogue software keep-alive behavior in the related art;

FIG. 2 is a schematic diagram of a set of dynamic detections provided by the related art;

FIG. 3 is a schematic diagram of a file lock reactivation mechanism according to an embodiment of the present application;

fig. 4 is a schematic hardware structure of an electronic device according to an embodiment of the present application;

Fig. 5 is a schematic software structure of an electronic device according to an embodiment of the present application;

FIG. 6 is a flowchart of a detection method according to an embodiment of the present application;

FIG. 7 is a flowchart of another detection method according to an embodiment of the present application;

FIG. 8 is a schematic diagram of a detection process according to an embodiment of the present application;

FIG. 9 is a schematic diagram of another detection process according to an embodiment of the present application;

Fig. 10 is a schematic diagram of a system on chip according to an embodiment of the present application.

Detailed Description

The terms "first" and "second" are used below for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include one or more such feature. In the description of the present embodiment, unless otherwise specified, the meaning of "plurality" is two or more.

Before introducing the software detection method provided by the embodiment of the application, related terms related to the method are briefly described here:

1. Rogue software.

Different from normal software which is developed for facilitating the work and entertainment of users by using the electronic equipment and is published publicly, rogue software is software which is installed and operated on the electronic equipment of the users under the condition that the users are not explicitly prompted or allowed by the users, and influences the user experience through malicious behaviors such as popup advertisements, information collection and the like.

2. A process.

A process is a running activity of software on a certain dataset, and is a basic unit of resource allocation and scheduling by an operating system (e.g., android ^TM system). Each process occupies a memory space, and software runs on an operating system in the form of one or more processes to realize corresponding functions.

3. And (5) a file lock.

File locks, or mutex locks, are mechanisms that ensure that only one process accesses a method or variable at a time. If the file lock is held by a process, other processes enter a waiting state when attempting to acquire the file lock, and only after the process releases the file lock, the other processes can acquire the file lock to access a corresponding method or variable.

The implementation of the present embodiment will be described in detail below with reference to the accompanying drawings.

With the rapid development of technology, electronic devices and applications thereof are becoming more and more popular, and play an important role in various fields of daily life. The electronic device can be provided with various software to meet different requirements of users, wherein the software comprises application software (applicationsoftware), system software (systemsoftware), middleware (middleware) and the like.

Rogue software (badware) in software is becoming more prevalent in open network environments. Rogue software is classified into spyware, behavior recording software, browser hijacking software, search engine hijacking software, advertising software, automatic dialing software, password stealing software, and the like. Rogue software has the characteristics of forced installation, difficult uninstallation, advertisement pop-up, malicious collection of user information and the like, and brings great inconvenience to users.

In order to implement advertisement and information collection in the electronic equipment of the user for a long time as possible, rogue software can not only run a great deal of activities (such as playing silent music and continuously pulling up new components) in the background to improve the running priority of the rogue software, but also passively prevent the rogue software from being cleaned by a system of the electronic equipment as an idle process; but also to actively restart the process (or keep-alive process) after it has been shut down by the user or system.

Referring to fig. 1, a schematic diagram of a rogue software keep-alive behavior in the related art is shown. Rogue software is an advertising application (DECEPTIVEADWARE) 101, and the advertising application 101 camouflages the icon pattern displayed on the first interface 102 as the icon pattern of the setup application 103. The user clicks on the advertising application 101 and can see in the second interface 104 that the progress of the advertising application 101 has been initiated. The user clicks the prompt information corresponding to the advertisement application 101 in the second interface 104, and switches to the third page 105, and in the third page 105, the user clicks the "forced stop" button 106, and the progress of the advertisement application 101 is not closed. The user will still see in the second interface 104 that the process of the advertising application 101 has started. That is, the advertisement application 101 can achieve the purpose of restarting even if the process is closed through the keep-alive behavior.

Aiming at the characteristic that rogue software has keep-alive behavior, the related technology can check whether the keep-alive behavior of the software is triggered to dynamically detect whether the software is the rogue software through the process of closing the software by the system. Specifically, the system or the user actively closes the process of the software, if the process of the software is closed, the process can be restarted again, and the software is described as rogue software, otherwise, the software is described as normal software.

Two dynamic detection modes are described below, one is the process of closing the software by the user, and the other is the process of closing the software by the system. Both modes have the common feature that whether the software is rogue software can be detected after the process of closing the software.

Referring to fig. 2, a schematic diagram of a set of dynamic detection provided by the related art is shown. In fig. 2 (a), the process of closing the software by the user includes: the electronic device displays a fourth interface 201, which may be an application list interface. When the user performs a first trigger operation 203 for the clear button 202 or a second trigger operation 204 for the advertisement application preview image 204 on the fourth interface 201, the progress of the application is closed. Wherein the first triggering operation 203 may be a click operation and the second triggering operation 204 may be a slide operation.

In fig. 2 (b), the system shuts down the process of the software, including: the system acquires a process group corresponding to the advertisement application; for each group of process groups, the system freezes the process groups so that the process groups cannot communicate across processes, and then kills the process groups for a plurality of times, thereby ensuring that the processes are successfully shut down. The above operations are repeated for each set of process groups of the advertising application until all process groups of the advertising application are closed.

Since the dynamic detection method needs to close the process of the application, the application of the closed process cannot continue to provide services for the user. If the application is a safety protection type application, once the process is closed, the capability of protecting the system is lost, and some risk behaviors may jeopardize the system safety; if the application is a messaging application, once the process is closed, the user cannot receive information in time. Therefore, by closing the process of the software, whether the software has a dynamic detection mode of keep-alive behavior is checked, normal use of the electronic equipment is affected, and inconvenience is brought to a user. Thus, it is necessary to determine whether the software is rogue by detecting whether the software has keep-alive by means of static detection, i.e. without shutting down the process of the software.

It has been found that the keep-alive behavior of rogue software is achieved through a file lock reactivation mechanism. Specifically, referring to fig. 3, a schematic diagram of a file lock reactivation mechanism according to an embodiment of the present application is shown. The system starts a process 301 and a process 302 for the advertisement application 101, wherein the process 301 holds a file lock x, and the process 302 holds a file lock y; the process 301 attempts to acquire the file lock y held by the process 302 on the basis of holding the file lock x. However, because file lock y is exclusive, i.e., it is rejected from being acquired by process 301 during the time that it is held by process 302, process 301 is waiting. When process 302 is closed, process 301 in a waiting state will acquire file lock y, then process 302 may sense (or snoop) that the file lock y held by process 302 is released as process 302 is closed, and process 301 then restarts closed process 302.

The normal software may cause the electronic device to take the normal software as white list software by requesting the white list service from a service provider of the electronic device. When the white list software runs in the background, the process of the white list software cannot be actively closed by the system of the user and the electronic equipment, so that the normal software can avoid closing the process without a file lock reviving mechanism. One way to distinguish between rogue software and normal software may be to detect whether the software uses a file lock reactivation mechanism, and if so, to determine that the software is rogue software, and otherwise, to determine that the software is normal software.

The embodiment of the application provides a software detection method, which is applied to electronic equipment. If the electronic device determines that the software to be detected includes a plurality of target processes that satisfy the preset condition, the electronic device detects that the software to be detected is the target software (or rogue software). The preset conditions comprise: any one of the plurality of target processes is in a waiting state for waiting to acquire a file lock held by a first process of the plurality of target processes, and the file lock held by any one of the plurality of target processes is also waiting to be acquired by a second process of the plurality of target processes, the first process being different from the second process. According to the method, whether the to-be-detected software is kept alive by a file lock reviving mechanism or not is determined according to the fact that whether a plurality of processes are mutually kept in the to-be-detected software or not in the running process of the to-be-detected software, so that the to-be-detected software is detected to be rogue software, the processes of the to-be-detected software do not need to be closed in the running process of the to-be-detected software, the rogue software can be identified through the detected keep alive behaviors of the to-be-detected software, normal use of the to-be-detected software is not affected, and user experience is good.

Where N target processes are arranged based on a file lock wait relationship, the multiple processes daemon each other refers to a daemon relationship that forms an end-to-end connection between N target processes, e.g., the nth target process daemon the 1 st target process, the 1 st target process daemon the 2 nd target process … th-1 st target process daemon the nth target process. Then in the case that any one of the N target processes is closed, the daemon of the N target processes releases the waiting state of the file lock from the waiting target process and switches to holding the file lock that the target process has held, and then the daemon restarts the closed target process, so that the software to be detected can keep alive the process.

Illustratively, A, B, C, D, E are 5 processes of the software to be tested, (A→B→C→D→E→A) representing A daemon B, B daemon C, C daemon D, D daemon E, E daemon A. Because the head and tail guard is carried out among the 5 processes, any one process is closed and can be timely discovered and restarted by other processes. And (A.fwdarw.B.fwdarw.C), (D.fwdarw.E.fwdarw.C) indicates A, D that there are no other process daemons, A daemons B, B and E daemons C, D daemons E, in which case if the system turns off processes A, B, C, D, E in order, all processes of the software may be detected. That is, a daemon relationship of head-to-tail connection is formed between N target processes in the software to be connected, and it is considered that any one of the N target processes can be discovered and restarted in time by other processes after being closed, so that the software to be detected is determined to be rogue software.

In embodiments of the present application, N > 2, and N is an integer, and N may be 3, 4, 5, 10, 15, etc., by way of example. The larger N is the longer the time reserved for the process to be detected to be closed and restarted, the higher the success rate of the process to be detected is, so that the problem that the process is restarted after a plurality of processes are closed in a short time, and the software is closed can be avoided. Since the normal software can avoid closing the process without a file lock reviving mechanism, the normal software also does not need to consider the problem of success rate of process restarting, so if the electronic device determines that the number N of target processes which are mutually daemon is more than 2, the software to be detected is considered to be deliberately provided with target processes with the number more than 2 in order to improve the success rate of process restarting, so that the problem that when a certain process is not restarted, the daemon process of the process is also closed, and the process cannot be restored is avoided, and then the software to be detected is identified as rogue software.

In the embodiment of the present application, the electronic device may be a portable computer (such as a mobile phone), a tablet computer, a notebook computer, a Personal Computer (PC), a wearable electronic device (such as a smart watch), an augmented reality (augmented reality, AR) \virtual reality (virtualreality, VR) device, a vehicle-mounted computer, or the like, and the specific form of the electronic device is not particularly limited in the following embodiments.

As shown in fig. 4, taking the example that the electronic device is a mobile phone, the mobile phone may include a processor 410, an external memory interface 420, an internal memory 421, a Universal Serial Bus (USB) interface 430, a charge management module 440, a power management module 441, a battery 442, an antenna 1, an antenna 2, a mobile communication module 450, a wireless communication module 460, an audio module 470, a speaker 470A, a receiver 470B, a microphone 470C, an earphone interface 470D, a sensor module 480, keys 490, a motor 491, an indicator 492, a camera 493, a display screen 494, and a subscriber identity module (subscriber identificationmodule, SIM) card interface 495, etc.

The sensor module 480 may include a pressure sensor, a gyroscope sensor, a barometric sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a proximity sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, and the like.

It should be understood that the structure illustrated in this embodiment is not limited to a specific configuration of the mobile phone. In other embodiments, the handset may include more or fewer components than shown, or certain components may be combined, or certain components may be split, or different arrangements of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

The processor 410 may include one or more processing units, such as: the processor 410 may include an application processor (applicationprocessor, AP), a sensor hub (sensorhub), a modem processor, a graphics processor (graphics processingunit, GPU), an image signal processor (imagesignalprocessor, ISP), a controller, a memory, a video codec, a digital signal processor (digitalsignalprocessor, DSP), a baseband processor, and/or a neural network processor (neural-networkprocessingunit, NPU), etc. Wherein the different processing units may be separate devices or may be integrated in one or more processors.

The controller may be a neural hub and command center of the electronic device. The controller can generate operation control signals according to the instruction operation codes and the time sequence signals to finish the control of instruction fetching and instruction execution.

A memory may also be provided in the processor 410 for storing instructions and data. In some embodiments, the memory in the processor 410 is a cache memory. The memory may hold instructions or data that the processor 410 has just used or recycled. If the processor 410 needs to reuse the instruction or data, it may be called directly from memory. Repeated accesses are avoided, reducing the latency of the processor 410 and thus improving the efficiency of the system.

In some embodiments, processor 410 may include one or more interfaces. The interfaces may include an integrated circuit (inter-integratedcircuit, I2C) interface, an integrated circuit built-in audio (inter-integratedcircuitsound, I2S) interface, a pulse code modulation (pulsecodemodulation, PCM) interface, a universal asynchronous receiver transmitter (universal asynchronousreceiver/transmitter, UART) interface, a mobile industry processor interface (mobileindustryprocessor interface, MIPI), a general-purposeinput/output (GPIO) interface, a subscriber identity module (subscriberidentitymodule, SIM) interface, and/or a Universal Serial Bus (USB) interface, among others.

It should be understood that the connection relationship between the modules illustrated in this embodiment is only illustrative, and does not limit the structure of the electronic device. In other embodiments, the electronic device may also use different interfacing manners in the foregoing embodiments, or a combination of multiple interfacing manners.

The electronic device implements display functions through the GPU, the display screen 494, and the application processor, etc. The GPU is a microprocessor for image processing, and is connected to the display screen 494 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 410 may include one or more GPUs that execute program instructions to generate or change display information.

The external memory interface 420 may be used to interface with an external memory card, such as a MicroSD card, to enable expansion of the memory capabilities of the electronic device. The external memory card communicates with the processor 410 through an external memory interface 420 to implement data storage functions. For example, files such as music, video, etc. are stored in an external memory card.

The internal memory 421 may be used to store computer-executable program code that includes instructions. The internal memory 421 may include a storage program area and a storage data area. The storage program area may store an operating system, an application program (such as a mechanism for detecting a reactivation of a file) required for at least one function, and the like. The storage data area may store data created during use of the electronic device (e.g., file lock information), and so on. In addition, the internal memory 421 may include a high-speed random access memory, and may also include a nonvolatile memory, such as at least one magnetic disk storage device, a flash memory device, a universal flash memory (universalflashstorage, UFS), and the like. The processor 410 performs various functional applications of the electronic device and data processing by executing instructions stored in the internal memory 421 and/or instructions stored in a memory provided in the processor.

The display screen 494 is used to display images, videos, and the like. The display screen may be a touch screen.

The touch screen may have a display screen 494 and a touch sensor, which detects a touch operation acting thereon or thereabout, and transmits touch data to the AP.

The display screen 494 includes a display panel. The display panel may employ a Liquid Crystal Display (LCD), an organic light-emitting diode (OLED), an active-or active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (flexlight-emittingdiode, FLED), miniled, microLed, micro-oLed, a quantum dot light-emitting diode (quantumdotlightemittingdiodes, QLED), or the like.

The electronic device may implement shooting functions through the ISP, the camera 493, the video codec, the GPU, the display screen 494, the application processor, and the like.

The ISP is used to process the data fed back by the camera 493. For example, when photographing, the shutter is opened, light is transmitted to the camera photosensitive element through the lens, the optical signal is converted into an electrical signal, and the camera photosensitive element transmits the electrical signal to the ISP for processing, so that the electrical signal is converted into an image visible to naked eyes. ISP can also optimize the noise, brightness and skin color of the image. The ISP can also optimize parameters such as exposure, color temperature and the like of a shooting scene. In some embodiments, an ISP may be provided in the camera 493.

The camera 493 is used to capture still images or video. The object generates an optical image through the lens and projects the optical image onto the photosensitive element. The photosensitive element may be a charge coupled device (chargecoupleddevice, CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the optical signal into an electrical signal, which is then transferred to the ISP to be converted into a digital image signal. The ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signal into an image signal in a standard RGB, YUV, or the like format. In some embodiments, the electronic device may include N cameras 493, N being a positive integer greater than 1.

The digital signal processor is used for processing digital signals, and can process other digital signals besides digital image signals. For example, when the electronic device selects a frequency bin, the digital signal processor is used to fourier transform the frequency bin energy, and so on.

Video codecs are used to compress or decompress digital video. The electronic device may support one or more video codecs. In this way, the electronic device may play or record video in a variety of encoding formats, such as: dynamic picture experts group (moving pictureexpertsgroup, MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

The NPU is a neural-network (NN) computing processor, and can rapidly process input information by referencing a biological neural network structure, for example, referencing a transmission mode between human brain neurons, and can also continuously perform self-learning. Applications such as intelligent cognition of electronic devices can be realized through the NPU, for example: image recognition, face recognition, speech recognition, text understanding, etc.

The software system of the electronic device may employ a layered architecture, an event driven architecture, a microkernel architecture, a microservice architecture, or a cloud architecture. In the embodiment of the application, a layered Android ^TM system is taken as an example, and the software structure of the electronic equipment is illustrated.

As shown in fig. 6, the layered architecture divides the software into several layers, each with a clear role and division of work. The layers communicate with each other through a software interface. In some embodiments, the Android ^TM system is divided into six layers, namely an application layer, an application framework layer (abbreviated as framework layer), an Zhuoyun row (Android ^TM runtime) and a system library, a hardware abstraction layer (hardwareabstractionlayer, HAL), a kernel layer and a driving layer from top to bottom. The lower layer of the driving layer also comprises a hardware layer.

The application package may include Applications (APP) such as camera, calendar, map, video, music, short message, gallery, talk, bluetooth, video clip, etc.

These APPs are typically written in java language, each of which includes one or more class (class) files. Each APP may run a respective class file in the application layer in the form of a process. When a user operates in the APP, the APP can interact with the system library or the kernel layer by calling related application programming interfaces (applicationprogramminginterface, APIs) or services (services) in the application framework layer to realize functions corresponding to the operation.

In addition, the application layer also includes Android core applications such as a launcher (the launcher may include a desktop and other components). Generally, the launcher can be used as a core application to be resident in the Android system to run after the Android ^TM system is started. The application start icon is generally set in the counter, and the counter can monitor the operation of clicking the start icon of an application by a user, generate a start message of the application, send the start message to related services in the application framework layer, and start an application process of the application through the services.

The framework layer provides APIs and programming frameworks for application programs of the application layer. The framework layer includes some predefined functions. The framework layer may include a window manager, a content manager, a view system, a telephony manager, a resource manager, a notification manager, an activity manager, and the like.

The view system comprises visual controls, such as a control for displaying characters, a control for displaying pictures and the like. The view system may be used to build applications. The display interface may be composed of one or more views. For example, a display interface including a text message notification icon may include a view displaying text and a view displaying a picture.

The resource manager provides various resources for the application program, such as localization strings, icons, pictures, layout files, video files, and the like.

The window manager is used for managing window programs. The window manager may obtain the display screen size, determine if there is a status bar, lock the screen, intercept the screen, etc.

The activity manager is used for managing the life cycle of each application program and the navigation rollback function, and is responsible for the creation of the main thread of Android ^TM and the maintenance of the life cycle of each application program.

As shown in fig. 5, a system service (SYSTEMSERVER) process and a hatching (zygote) process run in the framework layer. Among other things, SYSTEMSERVER processes can provide system services for APP in the application layer, such as system services including activity management services (ACTIVITYMANAGERSERVICE, AMS), power management services (powermanagerservice, PMS), window management services (windowmanagerservice, WMS), network management services (networkmanagementservice, NMS), and input method management services (inputmanagerservice, IMS), among others. These system services may reside in the SYSTEMSERVER processes in the form of threads.

Zygote processes are a very important daemon service (daemonservice) in the Android ^TM system, and almost all application processes come out through zygote process incubation (fork). Since the individual applications are written in the Java language, each application needs to run in the form of a process in a separate virtual machine (dalvik). When the application is started, the virtual machine of the application can be hatched out through the zygote process, so that the memory of the virtual machine and various services provided in the SYSTEMSERVER process are shared.

Typically, after the lawncher monitors that the user clicks on a launch icon of an application (e.g., gallery APP), a launch message of the application may be sent to the SYSTEMSERVER process. If no application process exists in the current application process, which means that the application process needs to be re-created for the application at this time, then SYSTEMSERVER processes can call the AMS to communicate with zygote processes, request zygote processes to create corresponding application processes for the application, and realize cold start of the application.

Taking the gallery APP as an example, after the lawncher monitors the triggering operation of the user on the start icon of the gallery APP, a start message of the gallery APP may be sent to the SYSTEMSERVER process. If no gallery APP application process exists in the current application process, then SYSTEMSERVER processes may call the AMS to send a request for creating an application process to zygote processes through a socket. Upon receipt of the creation request by the zygote process, an application process 1 of the gallery APP may be created in response to the creation request, the application process 1 typically including the main thread of the application (ACTIVITYTHREAD). In order to start to normally run codes in the gallery APP, after the application process 1 of the gallery APP is created, the main thread of the application needs to be initialized, and class files of the gallery APP are loaded into the memory. To increase the available memory of gallery APP, more application processes, such as application process 2, application process 3 …, application process n, may be created for gallery APP. If the gallery APP is normal software, multiple application processes of the gallery APP are not mutually daemon. If the gallery APP is rogue software, then multiple application processes of the gallery APP will daemon each other to avoid the gallery APP being closed by the system or by the user.

As shown in fig. 2, the system library may include a plurality of functional modules. For example: a surface manager (surfacemanager), a media library (medialibraries), a three-dimensional graphics processing library (e.g., openGLES), a two-dimensional graphics engine (e.g., SGL), and the like.

The surface manager is used to manage the display subsystem and provides a fusion of 2D and 3D layers for multiple applications. Media libraries support a variety of commonly used audio, video format playback and recording, still image files, and the like. The media library may support a variety of audio and video encoding formats, such as MPEG4, h.264, MP3, AAC, AMR, JPG, PNG, etc. The three-dimensional graphic processing library is used for realizing three-dimensional graphic drawing, image rendering, synthesis, layer processing and the like. The two-dimensional graphics engine is a drawing engine for 2D drawing.

Androidruntime include core libraries and virtual machines. Androidruntime is responsible for scheduling and management of the android system.

The core library consists of two parts: one part is a function which needs to be called by java language, and the other part is a core library of android.

The application layer and the application framework layer run in a virtual machine. The virtual machine executes java files of the application program layer and the application program framework layer as binary files. The virtual machine is used for executing the functions of object life cycle management, stack management, thread management, security and exception management, garbage collection and the like.

The kernel layer is a layer between hardware and software. The inner core layer at least comprises display drive, camera drive, audio drive, sensor drive and the like. The camera driving is a driving layer of the camera and is mainly responsible for interaction with hardware. For example, a camera driver may activate a camera of a hardware layer, and the activated camera may collect image data.

In the software detection method provided by the embodiment of the application, when the user is detected to open the software to be detected, the software detection service in the framework layer can acquire the file lock information of the software to be detected, determine whether the software to be detected comprises a plurality of target processes meeting the preset condition based on the file lock information, and if the software to be detected comprises a plurality of target processes meeting the preset condition, determine that the software to be detected is rogue software, and the software detection service can report the detection result to the security protection class application of the application program layer.

The following takes an example that the electronic device is a mobile phone, and the method provided by the embodiment of the application is described with reference to the accompanying drawings.

The embodiment of the application provides a software detection method, which is used for identifying whether the software to be detected has keep-alive behavior in a static observation mode under the condition that the process of the software to be detected is not closed in the running process of the software to be detected so as to determine whether the software to be detected is rogue software, as shown in fig. 6, and the method comprises the following steps:

S601, running software to be detected.

The software to be detected can run in the foreground or in the background.

In some embodiments, running the software to be detected includes: the mobile phone receives a first control instruction of a user, wherein the first control instruction is used for starting software to be detected; and responding to the first control instruction, and starting a plurality of processes of the software to be detected by the mobile phone so that the software to be detected runs in the foreground.

Or running the software to be detected includes: the mobile phone receives a second control instruction sent by the software to be detected, wherein the second control instruction is used for controlling the software to be detected to be switched from a foreground to a background of the mobile phone and then continuously using mobile phone resources; and responding to the second control instruction, and running the software to be detected in the background.

In the embodiment of the application, the software to be detected comprises: application software to be detected, system software to be detected and middleware to be detected. Among these, application software is a collection of various programming languages that can be used by users, and applications programmed in various programming languages, such as cameras, calendars, maps, videos, and the like, as mentioned above. The system software is responsible for managing the various independent hardware in the computer system so that they can work in concert, and includes an operating system, a compiler, a database management system, and the like. Middleware is a type of computer software that connects software components to applications to facilitate communication between the components of the software.

In the running process of the software to be detected, the process information of the software to be detected can be acquired by the mobile phone. The process information comprises the number information of the process, and different processes can be distinguished according to the number information. The process information further includes file lock information held by the process and file lock information that the process attempts to acquire, and the description of S602 may be referred to specifically.

S602, acquiring file lock information of the software to be detected.

A process list is preset in the mobile phone, and information related to the process of the software is stored. The mobile phone starts the software to be detected by starting the process of the software to be detected, so that the software to be detected is started and kept running, and the process information of all the processes of the software to be detected can be obtained by inquiring the process list of the software to be detected in the running process of the software to be detected. The process information comprises the number information of the process and the number information of the software corresponding to the process. If the number information of the software of the plurality of processes is the same, the plurality of processes are indicated to be the same process of the software to be detected.

The mobile phone is also preset with a file lock list for storing information related to the file lock of the software. For example, in the Android ^TM system, all file lock information in the file lock list can be queried through the "/proc/locks" node. The file lock information includes the number information of the file lock, and in the case where a process attempts to hold the file lock of another process, the file lock information also includes a wait identification. The file lock information is used for determining that the process of the software to be detected holds a file lock or that the process of the software to be detected is in a waiting state for other processes to release the file lock. When the waiting flag is included in the file lock information, it means that the process of the software to be detected tries to hold the file lock of the other process. When the file lock information does not include the waiting mark, the process of the software to be detected is indicated to hold the file lock. Wherein the waiting identity may be denoted "- >". The mobile phone can acquire file lock information related to the software to be detected from the file lock list according to the serial number information of each process of the software to be detected.

Illustratively, the input "/proc/locks" looks at all file locks in the system, where "23: FLOCKADVISORY WRITE26092fd:0c:642140EOF "and" 23: - > FLOCKADVISORYWRITE26107fd:0c:642140EOF "are the file lock information of the process with the number information 26092 and the file lock information of the process with the number information 26107 of the software to be detected, respectively. "23: FLOCKADVISORYWRITE26092fd:0c:642140EOF "means that the process with the number information 26092 of the software to be detected holds a lock of file fd:0c:64214," 23: - > FLOCKADVISORY WRITE26107fd:0c:642140EOF "means that the process with the number information 26107 of the software to be detected is in a waiting state in which the lock of the waiting file fd:0c:64214 is released, i.e. the process with the number information 26107 is in a waiting state in which the process with the number information 26092 releases the lock of the file.

It should be noted that if the process list and the file lock list are not preset in the mobile phone, the mobile phone may create a new process list and a new file lock list for storing the information related to the process and the information related to the file lock.

S603, judging whether the software to be detected comprises N target processes meeting preset conditions according to the file lock information.

Wherein N is more than 2, and N is an integer; the preset conditions comprise: any one of the N target processes is in a waiting state for waiting to acquire a file lock held by a first process of the N target processes, and the file lock held by any one of the N target processes is also waiting to be acquired by a second process of the N target processes, wherein the first process is different from the second process.

Under the condition that N target processes are arranged based on a file lock waiting relationship, the ith target process in the N target processes is in a waiting state for waiting for the (i+1) th target process in the N target processes to release the file lock, and the Nth target process in the N target processes is in a waiting state for waiting for the 1 st target process in the N target processes to release the file lock, wherein i is less than N-1, and i is an integer greater than 0.

As mentioned above, the file lock information may determine the number information of the file lock held by the process and the number information of the file lock that the process tries to acquire, if a file lock is held by both process 1 (corresponding to any of the above processes) and is tried to acquire by process 2 (corresponding to the above first process), then with respect to the file lock, process 1 and process 2 form a daemon relationship of process 2 daemon 1. Since the presence of only a one-way daemon is not yet sufficient to be able to restart process 2 when process 2 is shut down, process 2 needs to be daemon by a process other than itself. The process may be process 1 or process 3 (corresponding to the second process above).

In the case of the process 1 daemon 2, the process 1 and the process 2 daemon each other to form a process pair consisting of two processes, and the processes in the process pair form an end-to-end daemon relationship. However, since the number of processes in the process pair is too small, it is easy for the process 2 not to restart the process 1 in time after the process 1 is closed, and the process 2 is also closed, so that the whole process pair is closed, and therefore, the possibility that the process 1 can be restarted under the circumstance of daemon is low, and in general, rogue software does not adopt a mode that the process 1 and the process 2 daemon each other.

In the case where process 3 daemons process 2, and process 3 is different from process 1, process 2 may switch to a holding state based on the wait state of the file lock attempting to acquire process 1, perceiving that process 1 is turned off. Even if the process 2 is not started in time and the process 1 is closed, the process 3 can sense that the process 2 is closed and restart the process 2 in time, and after the process 2 is restarted, the process 1 is restarted, so that the processes are mutually guarded.

In the above embodiment, if the process 3 is first turned off, since there is no daemon of the daemon 3, the process 3 cannot be restarted, and then the daemon 2 of the daemon 3 cannot be restarted after being turned off, and the daemon 1 of the daemon 2 cannot be restarted after being turned off, so that the processes 3, 2, and 1 are turned off successively. To avoid this problem, the daemon relationship in each process should be a directed ring, and any process in the directed ring needs to daemon other processes and be daemon by other processes, so that it can be guaranteed that any process is turned off and restarted by other processes.

Based on this, whether the software to be detected includes N target processes satisfying the preset condition can be understood as whether the daemon relationship of the multiple processes in the software to be detected is a directed ring with the number of processes being greater than 2. As shown in FIG. 7, S603 may further include S603a-S603b.

S603a, determining that at least one group of process groups exists in the software to be detected according to the file lock information, determining that any process in the process groups is in a waiting state that any other process in the waiting process groups releases the file lock, and determining that the process in the process groups is a target process if the file lock held by the process is also attempted to be acquired by any other process in the process groups.

In S603a, any process x in the process group is in a waiting state for any other process y in the process group to release the file lock m, which means that in the case that the process x switches from the waiting state for waiting for release of the file lock m to the holding state for holding the file lock m, the process x can determine that the file lock held by the process y is released, and further determine that the process y is closed, then the process x restarts the process y, so that the process y continues to run, that is, so the process x daemon y. The file lock held by the process x is also tried to be acquired by any other process z in the process group, which means that the process z is released through the file lock of the process x, and can determine that the process x is closed, so that the process x is restarted, and the function of continuously running the daemon x is achieved. The multiple processes in the process group are in an end-to-end daemon relationship, i.e., the daemons of the multiple processes form a directed ring.

S603b, judging whether the number N of the target processes is larger than 2.

To increase the success rate of a process being restarted, the number of processes in the directed ring of processes of rogue software is typically greater than 2, avoiding that the processes of the software are shut down, reserving a long enough time for one process to be shut down to restart. Whether the number N of target processes is greater than 2 can be taken as a condition for judging rogue software and normal software.

Through the above S603a-S603b, the mobile phone determines a directed ring of process pairs from the processes of the software to be detected, and then determines whether the number of process pairs in the directed ring is greater than 2, thereby determining whether the software to be detected is rogue software. If the process pairs forming the directed ring exist in the processes of the software to be detected, but the number of the process pairs is less than or equal to 2, or the process pairs forming the directed ring do not exist in the processes of the software to be detected, determining that the software to be detected is not rogue software. If the process pairs forming the directed ring exist in the processes of the software to be detected, and the number of the processes in the process pairs is more than 2, determining that the software to be detected is rogue software.

In some embodiments, in order to improve detection efficiency, a process and a daemon may be represented by a directed graph, where the process is used as a vertex of the directed graph, and the daemon is used as an edge of the directed graph, and whether the software to be detected includes N target processes meeting a preset condition is determined by determining whether a plurality of vertices in the directed graph form a directed ring, and the number of vertices in the directed ring is greater than 2.

Specifically, as shown in fig. 8, all processes of the software to be detected are obtained from the file lock information, each process is used as a vertex of a directed graph, and an initial graph with only vertices and no edges is generated.

Inquiring the held process and the process which is attempted to be acquired of each file lock in the file lock information, and aiming at any process x, if another process y is attempted to acquire the file lock of the process x, pointing the node corresponding to the other process y to the node corresponding to the process x to obtain a directed edge indicating the waiting relationship between the process x and the process y; traversing all processes of the software to be detected, and constructing a directed edge in the initial graph to obtain the initial directed graph.

The outliers in the initial directed graph are deleted, where the outliers represent the directed edges that the vertex points to neither other vertices nor by other vertices. The orphan point corresponds to a process that holds a file lock in the software to be detected, but the file lock is not attempted to be acquired by other processes, and the process is not attempted to acquire the file lock held by other processes, namely, corresponds to a process that is not daemon of other processes in the software to be detected, and is not daemon of other processes.

And taking any vertex A except isolated points in the initial directed graph as a searching starting point, wherein the vertex A corresponds to a process x, and performing depth-first searching on the vertex A. When the vertex a is searched again, a directional path starting from the vertex a and ending at the vertex a is recorded, and the directional path is determined as a directional ring 1, and as shown in fig. 8, the thickened arrow and the pointed vertex form a directional ring.

And then, taking any vertex B except the isolated point and the vertex A in the initial directed graph as a searching starting point, and performing depth-first searching on the vertex B. When the vertex B is searched again, a directed path starting from the vertex B and ending at the vertex B is recorded, and the directed path is used as the directed ring 2.

And after performing depth-first search on all vertexes, deleting self-loops of the vertexes and the self-loops which are connected through directed edges to obtain target directed loops, and obtaining the number of target directed graphs and the number of vertexes in each target directed graph. If the number of vertices in any target directed graph is greater than 2, indicating that the software to be detected has a file lock revival mechanism, then the software to be detected is identified as rogue software.

In this embodiment, each search may be marked visited for a vertex that was visited, and if a vertex with a mark visited was visited, this would indicate that the vertex was searched. Specifically, vertex a is marked visited with vertex a as the search start point, and if the point with visited is encountered again in the search process, it is considered that multiple vertices exist in the traversed vertices to form a directed ring, so that the search is exited. And removing visited marks of all vertexes, and removing the vertex A from the list to be tested, wherein all vertexes except isolated points in the directed graph are preset in the list to be tested. After removing the vertex a, vertices in the directed graph other than the vertex a and the isolated point are also included in the to-be-tested list. And selecting the vertex B from any one of the lists to be tested, and repeating the searching process of the vertex A. In the event that a directed ring is searched, the directed ring may be indexed to avoid subsequent re-searching of the directed ring.

In some embodiments, instead of using a depth-first search, an outlier in the directed graph is deleted, a vertex in the directed graph with a number of directed edges pointing to other vertices of 0 is deleted, and a vertex in the directed graph with a number of directed edges pointing to other vertices of 0 is deleted, resulting in a directed ring or rings. If any directed ring exists, the number of vertices in the ring is greater than 2, the software to be detected is rogue software.

In some embodiments, where the number of target directed graphs is greater than 1, the software to be detected is identified as rogue software. Specifically, the rogue software can be realized by constructing a plurality of directed rings besides increasing the process restarting success rate by increasing the number of processes in one directed ring, even if all processes in one directed ring are killed, the processes in other directed rings can still be revived through the file lock, so that the software to be detected cannot be closed. In this case, therefore, it can be determined whether the software to be detected is rogue software by judging whether the number of target directed loops is greater than 1, so as to improve the probability that the rogue software is detected by the system.

In other embodiments, the software to be detected is identified as rogue software in the event that the number of vertices of at least two target directed graphs is greater than 2. That is, in this embodiment, only the software to be detected including a plurality of pairs of processes forming a directed ring daemon relationship, and the number of processes in each pair of processes being greater than 2, is used as rogue software, so as to reduce the probability of misjudging normal software as rogue software, thereby improving the detection accuracy.

S604, if yes, detecting that the software to be detected is rogue software.

And S605, if not, detecting that the software to be detected is not rogue software.

In S603, N target processes satisfying the preset condition exist in the plurality of processes of the rogue software, so that the target processes are mutually daemon, and thus, in the case that it is determined that the software to be detected includes N target processes satisfying the preset condition according to the file lock information, the software to be detected is identified as the rogue software; and under the condition that the software to be detected comprises N target processes which do not meet the preset conditions according to the file lock information, recognizing that the software to be detected is not rogue software.

The method provided by the embodiment of the application can identify whether the process of the software to be detected monitors the survival condition of other processes by attempting to acquire the file locks held by the other processes. And further distinguishing whether the software to be detected is normal software which deliberately realizes the keep-alive process through a file lock keep-alive mechanism or causes the files to be mutually deadlocked due to insufficient code quality according to whether the processes of the daemon other processes form a directed ring or not and the number of the processes. If the processes daemon other processes form directed loops and the number of directed loops is greater than 1 and/or the number of processes in the directed loops is greater than 2, then the software to be detected is determined to be rogue software. Therefore, not only can the rogue software be detected, but also the situation that some normal software which causes the deadlock of files due to insufficient code quality is misjudged as the rogue software is avoided, so that the detection accuracy is improved. In addition, the detection process is in the running process of the software to be detected, and the process of the software to be detected does not need to be closed, so that the method does not influence the normal use of the software to be detected, and the user experience is good.

For example, please refer to fig. 9, taking the software to be detected as an example of the application to be detected. The mobile phone acquires all processes of the application to be detected from the file lock information and records the processes in a table L_app. An empty list L_ filelock is then created for recording the file lock daemon.

Each process within l_app is traversed, for process x therein, to see if it owns file lock m. This step corresponds to S602 above.

If process x owns a file lock and there is another process y in table l_app attempting to acquire file lock m, and process y is in a wait state waiting for file lock m to be released because process x already holds file lock m, then process pair (y, x) is added to list l_ filelock. Where the process pair (y, x) corresponds to the directed graph in which process y points to process x, i.e. process y daemon x, in S603 above.

After all the processes in the table l_app are traversed, it is queried whether there are multiple groups of process pairs in the list l_ filelock, and after combination, an end-to-end loop may be formed, for example, a points to c, b points to c, c points to d, and d points to a.

If there are multiple groups of process pairs that can form an end-to-end loop, the number of process pairs is obtained.

If the number of process pairs is greater than 2, determining that the software to be detected is rogue software.

In order to further improve the detection accuracy, the threshold of the number of process pairs may be set to 10, that is, in the case that the number of process pairs is greater than 10, it is determined that the software to be detected is rogue software, so as to avoid misjudging normal software of accidental deadlock as the rogue software.

After detecting the rogue software, a prompt message may be displayed to remind the user that the mobile phone is running the rogue software, and the user may remove the rogue software from the mobile phone by uninstalling the rogue software. Or the mobile phone can record the event of detecting the rogue software in the log information so that the server or the mobile phone can maintain the system according to the log information.

Other embodiments of the present application provide an electronic device that may include: a display screen (e.g., a touch screen), a memory, and one or more processors. The display, memory, and processor are coupled. The memory is for storing computer program code, the computer program code comprising computer instructions. When the processor executes the computer instructions, the electronic device may perform the functions or steps performed by the mobile phone in the above-described method embodiments. The structure of the electronic device may refer to the structure of the electronic device shown in fig. 4.

The embodiment of the application also provides a chip system which can be applied to the electronic equipment in the previous embodiment. As shown in fig. 10, the system-on-chip includes at least one processor 2201 and at least one interface circuit 2202. The processor 2201 may be a processor in an electronic device as described above. The processor 2201 and the interface circuit 2202 may be interconnected by wires. The processor 2201 may receive and execute computer instructions from the memory of the electronic device described above through the interface circuit 2202. The computer instructions, when executed by the processor 2201, may cause the electronic device to perform the various steps described in the embodiments above. Of course, the system-on-chip may also include other discrete devices, which are not particularly limited in accordance with embodiments of the present application.

The embodiment of the application also provides a computer readable storage medium, which comprises computer instructions, when the computer instructions run on the electronic device, the electronic device is caused to execute the functions or steps executed by the mobile phone in the embodiment of the method.

The embodiment of the application also provides a computer program product which, when run on a computer, causes the computer to execute the functions or steps executed by the mobile phone in the above method embodiment.

It will be apparent to those skilled in the art from this description that, for convenience and brevity of description, only the above-described division of the functional modules is illustrated, and in practical application, the above-described functional allocation may be performed by different functional modules according to needs, i.e. the internal structure of the apparatus is divided into different functional modules to perform all or part of the functions described above.

In the several embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the modules or units is merely a logical functional division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another apparatus, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other forms.

The units described as separate parts may or may not be physically separate, and the parts displayed as units may be one physical unit or a plurality of physical units, may be located in one place, or may be distributed in a plurality of different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a readable storage medium. Based on such understanding, the technical solution of the embodiments of the present application may be essentially or a part contributing to the prior art or all or part of the technical solution may be embodied in the form of a software product stored in a storage medium, including several instructions for causing a device (may be a single-chip microcomputer, a chip or the like) or a processor (processor) to perform all or part of the steps of the method described in the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read Only Memory (ROM), a random access memory (random accessmemory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

The foregoing is merely illustrative of specific embodiments of the present application, but the scope of the present application is not limited thereto, and any changes or substitutions within the technical scope of the present application should 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 software detection method, applied to an electronic device, the method comprising:

running software to be detected on the electronic equipment;

If the software to be detected comprises a plurality of target processes meeting preset conditions based on the file lock information of the software to be detected, detecting that the software to be detected is target software; the file lock information is used for indicating that the process of the software to be detected holds a file lock or that the process of the software to be detected is in a waiting state for waiting to acquire the file lock held by other processes; the preset conditions include: any one of the plurality of target processes is in a waiting state for waiting to acquire a file lock held by a first process of the plurality of target processes, and the file lock held by the any one process is also waiting to be acquired by a second process of the plurality of target processes, wherein the first process is different from the second process.

2. The method of claim 1, wherein the determining that the software to be detected includes a plurality of target processes that satisfy a preset condition includes:

Acquiring processes in the software to be detected, wherein each process with a file lock in the processes of the software to be detected corresponds to a node;

aiming at any process, if another process is in a waiting state for obtaining a file lock held by the process, pointing a node corresponding to the other process to the node corresponding to the process, and obtaining a directed edge for indicating a waiting relationship between the two processes;

deleting nodes with the number of directed edges being 0 in the nodes and nodes with the number of directed edges being 0 pointed by other nodes to obtain at least one directed ring;

and determining the process corresponding to the nodes in the directed ring with the number of the nodes being more than 2 as the target process.

3. The method according to claim 1 or 2, characterized in that the method further comprises:

Acquiring file lock information of the software to be detected, wherein the file lock information is used for indicating that a process of the software to be detected holds a file lock or that the process of the software to be detected is in a waiting state for waiting to acquire the file lock held by other processes;

if a process holds a file lock or the process waits for acquiring the file lock, the process corresponds to the file lock;

and if the same file lock corresponds to a plurality of processes according to the file lock information, determining that one process in the plurality of processes is in a waiting state for waiting to acquire the file lock held by another process in the plurality of processes.

4. A method according to claim 3, wherein said obtaining file lock information of said software to be detected comprises:

Acquiring process information of the software to be detected, wherein the process information comprises serial number information of the software to be detected and serial number information of a process;

Acquiring file lock information associated with the process according to the serial number information of the process;

and acquiring file lock information associated with the process corresponding to the software to be detected according to the corresponding relation between the number information of the software to be detected and the number information of the process.

5. The method of claim 4, wherein the file lock information includes file lock numbering information; the obtaining the file lock information associated with the process according to the number information of the process comprises the following steps:

If the number information of the file lock corresponds to the number information of the process and the number information of the file lock carries a waiting identifier, determining that the file lock is waiting for acquisition by the process corresponding to the number information of the process; acquiring the number information of the file lock waiting to be acquired by the process and the waiting identification;

If the number information of the file lock corresponds to the number information of the process and the number information of the file lock does not carry a waiting mark, determining that the file lock is held by the process corresponding to the number information of the process; and acquiring the number information of the file lock held by the process.

6. The method of claim 1 or 2, wherein the number of the plurality of target processes is N, N is greater than 2 and N is an integer;

Under the condition that the N target processes are arranged based on the file lock waiting relationship, the ith target process in the N target processes is in a waiting state for waiting to acquire the file lock held by the (i+1) th target process in the N target processes, and the nth target process in the N target processes is in a waiting state for waiting to acquire the file lock held by the (1) st target process in the N target processes, wherein i is less than N-1, and i is an integer greater than 0.

7. The method according to claim 1 or 2, wherein said determining that the software to be detected includes a plurality of target processes that satisfy a preset condition includes:

and determining that the software to be detected comprises at least two groups of a plurality of target processes meeting the preset conditions.

8. The method according to claim 1 or 2, characterized in that the method further comprises: and if the software to be detected does not comprise a plurality of target processes meeting the preset conditions, detecting that the software to be detected is not the target software.

9. An electronic device, comprising: a processor, a memory storing the processor-executable instructions, the processor configured to, when executed, cause the electronic device to implement the method of any of claims 1-8.

10. A computer readable storage medium comprising computer instructions which, when run on the electronic device, cause the electronic device to perform the method of any of claims 1-8.