CN113366477A

CN113366477A - Malicious fast application detection method and terminal

Info

Publication number: CN113366477A
Application number: CN201980090970.6A
Authority: CN
Inventors: 郭子亮
Original assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd; Shenzhen Huantai Technology Co Ltd
Current assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd; Shenzhen Huantai Technology Co Ltd
Priority date: 2019-05-22
Filing date: 2019-05-22
Publication date: 2021-09-07
Also published as: WO2020232685A1

Abstract

The invention provides a detection method of malicious quick application and a terminal. The method comprises the following steps: when detecting that the instrumentation code is triggered, determining whether an application program calling interface API corresponding to the instrumentation code is a target API or not according to a triggering strategy; if the API corresponding to the instrumentation code is a target API, acquiring a log of a fast application calling the target API; judging whether the operation of triggering the instrumentation code is a risk operation or not according to the log of the fast application and a detection model; and if the operation of triggering the instrumentation code is a risk operation, sending the identification of the fast application and a judgment result to a cloud server. Therefore, the malicious study and judgment of the quick application is carried out in a mode of collecting the logs in the running process in real time, the malicious quick application can be rapidly determined, and then the cloud server is promoted to process the malicious quick application so as to prevent the malicious quick application from harming the user.

Description

Malicious fast application detection method and terminal

Technical Field

The invention relates to the field of terminals, in particular to a detection method for malicious quick application and a terminal.

Background

The fast application (quick app) is a novel application form based on a mobile phone hardware platform. The user does not need to download and install, namely, the user can use the application point-to-point, and the user can enjoy the performance experience of the native application. At present, with the development of fast applications, more and more fast applications appear in people's lives, such as code scanning, riding, and food ordering applications.

At present, the fast applications developed based on the terminal are checked (manually operated or machine-scanned rpk files) before being released, the fast applications are put on shelf after the checking is passed, and the fast applications which are not passed are not put on shelf. However, the technology that is only audited before release is easily bypassed by the killing-free technology of the malicious developer, and causes harm to the user.

Disclosure of Invention

The embodiment of the invention provides a detection method and a terminal for malicious quick application, which are used for conducting malicious research and judgment on quick application in a mode of collecting logs of an application program in real time, have strong anti-killing capability and improve user experience.

The first aspect of the embodiment of the invention discloses a method for detecting malicious fast application, which comprises the following steps:

when detecting that the instrumentation code is triggered, determining whether an Application Programming Interface (API) corresponding to the instrumentation code is a target API according to a triggering strategy;

if the API corresponding to the instrumentation code is a target API, acquiring a log of a fast application calling the target API;

judging whether the operation of triggering the instrumentation code is a risk operation or not according to the log of the fast application and a detection model;

and if the operation of triggering the instrumentation code is a risk operation, sending the identification of the fast application and a judgment result to a cloud server.

The second aspect of the present invention discloses a method for acquiring a detection model, which includes:

acquiring historical operating data of the fast application;

training the historical operating data by using a machine learning algorithm to obtain a detection model;

and sending the detection model to a terminal.

A third aspect of the present invention discloses a terminal, including:

the device comprises a determining unit, a judging unit and a judging unit, wherein the determining unit is used for determining whether an Application Programming Interface (API) corresponding to an instrumentation code is a target API or not according to a triggering strategy when the instrumentation code is detected to be triggered;

the acquiring unit is used for acquiring a log of a fast application calling the target API if the API corresponding to the instrumentation code is the target API;

the judging unit is used for judging whether the operation of triggering the instrumentation code is a risk operation or not according to the log of the fast application and a detection model;

and the sending unit is used for sending the identifier of the fast application and the judgment result to a cloud server if the operation of triggering the instrumentation code is a risk operation.

A fourth aspect of the present invention discloses a cloud server, including:

the acquisition unit is used for acquiring historical operating data of the fast application;

the training unit is used for training the historical operating data by utilizing a machine learning algorithm to obtain a detection model;

and the sending unit is used for sending the detection model to the terminal.

A fifth aspect of the present invention discloses a storage medium having a program stored therein; when the program is run, the processor performs the method of the first aspect or the second aspect.

A sixth aspect of the present invention discloses a terminal, comprising a processor and a memory; the memory stores a program; when the program is run, the processor performs the method of the first aspect.

It can be seen that in the scheme of the embodiment of the present invention, when it is detected that an instrumentation code is triggered, whether an application program call interface API corresponding to the instrumentation code is a target API is determined according to a trigger policy; if the API corresponding to the instrumentation code is a target API, acquiring a log of a fast application calling the target API; judging whether the operation of triggering the instrumentation code is a risk operation or not according to the log of the fast application and a detection model; and if the operation of triggering the instrumentation code is a risk operation, sending the identification of the fast application and a judgment result to a cloud server. Therefore, the malicious study and judgment of the quick application is carried out in a mode of collecting the logs in the running process in real time, the malicious quick application can be rapidly determined, and then the cloud server is promoted to process the malicious quick application so as to prevent the malicious quick application from harming the user.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings needed to be used in the embodiments will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present invention, and it is obvious for those skilled in the art that other drawings can be obtained according to these drawings without creative efforts.

Fig. 1 is a schematic structural diagram of a malicious fast application detection system according to an embodiment of the present invention;

fig. 2 is a schematic flowchart of a detection model training process for malicious applications according to an embodiment of the present invention;

fig. 3 is a schematic flowchart of a malicious fast application detection method according to an embodiment of the present invention;

fig. 4 is a flowchart illustrating another malicious fast application detection method according to an embodiment of the present invention;

fig. 5 is a flowchart illustrating another malicious fast application detection method according to an embodiment of the present invention;

fig. 6 is a schematic structural diagram of a terminal according to an embodiment of the present invention;

fig. 7 is a schematic structural diagram of a cloud server according to an embodiment of the present invention;

fig. 8 is a schematic physical structure diagram of a terminal according to an embodiment of the present invention;

fig. 9 is a schematic physical structure diagram of a mobile phone according to an embodiment of the present invention.

Detailed Description

The embodiment of the invention provides a detection method and a terminal for malicious fast applications, which can quickly identify the malicious fast applications and promote a cloud server to process the malicious fast applications so as to prevent the malicious fast applications from damaging users.

In order to make the technical solutions of the present invention better understood by those skilled in the art, the technical solutions in the embodiments of the present invention will be clearly described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some embodiments of the present invention, but not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

The appearances of the phrases "first," "second," and "third," or the like, in the specification, claims, and figures are not necessarily all referring to the particular order in which they are presented. Furthermore, the terms "include" and "have," as well as any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those steps or elements listed, but may alternatively include other steps or elements not listed, or inherent to such process, method, article, or apparatus.

In addition, the following embodiments of the present invention may employ the following terms, which are explained herein.

Fast application (quickapp): the method is a novel application form based on a mobile phone hardware platform. The user does not need to download and install, namely, the user can use the application point-to-point, and the user can enjoy the performance experience of the native application. The fast application framework is deeply integrated into mobile phone systems of various manufacturers, seamless connection between user requirements and application services can be achieved on the operating system level, user experience and conversion efficiency of the application services are improved, and meanwhile retention capabilities such as desktop icon generation and the like are supported.

rpk document: the source code and the resource of the fast application are compiled and packaged to generate a file, and the resource required by the running of the fast application is packaged and compressed into a file, and the compressed file is signed to obtain a final output, which is similar to an Android APK file (Android package).

Malicious quick application: fast applications that usually lose the user's interest without the user's knowledge.

A fast application engine: providing rpk a file runtime environment, which is essentially an APK, provides rpk with a series of interfaces (APIs).

Application Programming Interface (API): the fast application engine is an interface provided by a developer.

Killing is avoided: is the opposite of an Anti-virus (Anti virus) and an Anti-spy (Anti spyware), and is translated into Anti-virus technology in English. The technology can prevent virus trojan from being searched and killed by antivirus software. The non-killing virus refers to a virus file which is processed by a non-killing technology. The killing-free technology in the invention mainly refers to a technology used by a malicious fast application developer to escape or bypass a fast application platform auditing mechanism.

Monkey simulator: google provides Android application developers with a piece of stress testing software that tests the stress resistance of applications in high-stress use environments by randomly generating user touches and keyboard operations, which are used herein to simulate ordinary user input.

Pile inserting: a user-defined code is inserted into the code, and the user-defined code is executed in the running process of the program.

In an embodiment of the present invention, a malicious fast application detection system deployed in a terminal is disclosed, which can respond to detection in time, and has a very strong anti-killing capability, so that malicious fast applications can be found and disposed in time, and damage to users is avoided.

Specifically, as shown in fig. 1, the system mainly includes a part (or called a cloud server) deployed in the cloud and a part deployed in the terminal.

At the cloud end, the model training module is responsible for training and generating a detection model or a virus library from mass data and issuing the detection model or the virus library to a terminal for use; and the result processing module is responsible for receiving the detection result reported by the terminal and performing handling such as off-shelf processing on the malicious quick application.

At a terminal, an event monitor is pre-embedded in a fast application engine, piles are inserted at all API positions of the fast application engine, when an application runs on the terminal, pile inserting codes embedded at all API positions are triggered, and the API calling is recorded into a log; the vector generator is responsible for cleaning the log and generating a vector required by detection; and the analysis judger classifies the vectors according to the model issued by the cloud end so as to judge whether the fast application is malicious or not, and reports the result to the cloud end for disposal.

In terms of flow, the scheme mainly comprises a model training flow and a detection flow:

as shown in the training process of fig. 2, the model training is completed in the cloud, and the work flow of this part is as follows:

1) a batch of labeled training samples (RPK files) is selected indicating which risk behaviors the sample carries.

2) The samples are pushed one by one into the fast application engine, which has been pre-instrumented at various APIs.

3) The user's operation is simulated randomly using a tool such as Monkey.

4) At this time, the API of the fast application is triggered, the instrumentation code defined by us is run, the instrumentation code only needs to record the API call and output a log, and then the API call is completed by returning to the call address of the original API. The log contains at least four fields, fast application identification (marking which fast application this log is triggered by), behavior ID (ID of API triggered by fast application), behavior parameters (parameters of API triggered by fast application), and trigger time (time this API is triggered).

5) After the program runs for a period of time, we can obtain a behavior sequence, we convert the behavior sequence into a behavior vector, and the conversion mode can be various, for example: all behavior ids (numbers) are directly grouped into a string of numbers in the trigger time growth order. Or matching the behavior parameters by using a preset keyword library, and generating a vector by using the number of times of hitting the keywords.

6) And repeating the process until the behavior vectors of all the training set samples are obtained. And inputting the behavior vector and the label (including which risk behavior) of the sample corresponding to the behavior vector into a training program for training, and finally obtaining a model file. The training algorithm may be selected from many kinds, such as LSTM (Long Short-Term Memory network).

As shown in fig. 3, the detection part is performed on the terminal, and the working flow of the part is as follows:

1) when instrumentation code is triggered, the API call is first recorded as a log containing at least four fields, fast application identification, behavior id, behavior parameters, and trigger time (field meaning and consistency in the training process). And then returning to the calling address of the original API to finish API calling, wherein the following processes are all asynchronously carried out without blocking the calling of the API.

2) And matching a preset trigger strategy to judge whether detection is needed or not, because the number of instrumentation points is large, if each API is triggered, detection is carried out once, and the influence on the performance is large. The trigger policy can be customized according to actual situations, for example, if we pay attention to malicious fee deduction behaviors, we can define that detection is triggered each time when the short message sending API is triggered.

3) And if the trigger strategy judges that the behavior needs to be detected, all logs of the fast application are taken out from the logs, and a behavior vector is generated (the generation method needs to be consistent with the vector generation mode in the training phase). The analysis decision module is invoked using the behavior vector.

4) And the analysis and judgment module calls a prediction program of the model to judge the behavior vector by using the received behavior vector and the preloaded model file.

5) And if the judgment result shows that the behavior is risky, reporting the quick application identification and the detection result to the cloud end, and handling the quick application identification and the detection result by the cloud end.

Through the methods provided by fig. 2 and fig. 3, a batch of detection points may be preset in the fast application engine of the terminal to collect the running log of the fast application, the fast application is judged based on the generated log and the detection model, whether the fast application is malicious or not is detected, and the identification and the detection result of the malicious fast application are sent to the cloud for disposal (for example, the cloud may put the malicious fast application off shelf, etc.). And the cloud end trains to obtain a detection model by using the collected mass samples and behavior data, and sends the detection model to the terminal. In addition, the terminal can continuously receive the updated model issued by the cloud, so that the capability of continuously detecting the malicious quick application is achieved.

Referring to fig. 4, fig. 4 is a flowchart illustrating a method for detecting malicious fast applications according to an embodiment of the present invention. As shown in fig. 4, a method for detecting a malicious fast application according to an embodiment of the present invention includes the following steps:

s101, a cloud server acquires historical operating data of a fast application; training the historical operating data by using a machine learning algorithm to obtain a detection model; and sending the detection model to a terminal;

when it is required to be pointed out, the cloud server may be deployed in a centralized manner or in a distributed manner, and the deployment manner of the cloud server is not limited herein. In addition, the method for acquiring the detection model by the cloud server may refer to the method described in fig. 2, and details are not repeated here.

S102, the terminal receives the detection model sent by the cloud server and stores the detection model;

for example, the terminal may be an electronic device such as a smartphone, a tablet computer, a smart wearable device, a computer, and so on.

S103, when the instrumentation code is detected to be triggered, determining whether an Application Programming Interface (API) corresponding to the instrumentation code is a target API or not according to a triggering strategy;

wherein, it is pointed out that, the API can be inserted according to the requirement; all APIs may also be instrumented.

In addition, it can be understood that if the instrumented APIs are more, but for the purpose of targeted detection, a target API needs to be set, for example, the target API may be an API for making payment, for example, an API for extracting private information, and the like.

In addition, it should be noted that in the case of the foregoing, there are more instrumentation points, and if each API is triggered to perform a detection once, the performance is greatly affected. Optionally, the trigger policy may be customized according to actual situations, for example, if we pay attention to malicious fee deduction behaviors, we may define that detection is triggered each time the short message sending API is triggered.

In addition, optionally, the method further includes generating a log of the target application program according to a call record of the target API when the instrumentation code is detected to be triggered.

The instrumentation code is triggered, that is, the instrumentation code running the target API is quickly applied, and then the instrumentation code generates a log of the target application program according to a call record of the target API, and then returns to a call address of the target API to complete the call of the target API. Wherein the log comprises a fast application identifier, a behavior parameter, and a trigger time.

S104, if the API corresponding to the instrumentation code is a target API, acquiring a log of a fast application calling the target API;

for example, if the API corresponding to the instrumentation code is the target API, that is, the behavior at this time needs to be detected is determined according to the trigger policy, all logs of the fast application are taken out from the logs.

S105, judging whether the operation of triggering the instrumentation code is a risk operation or not according to the log of the fast application and a detection model;

optionally, the determining, according to the log of the fast application and the detection model, whether an operation that triggers the instrumentation code is a risk operation includes: generating a behavior vector according to the log of the fast application; matching the behavior vector with the detection model; and judging whether the operation of triggering the instrumentation code is risk operation or not according to the matching result.

It should be noted that the method for generating the behavior vector must be consistent with the vector generation mode in the training phase. Therefore, the terminal can send a vector generation method acquisition request to the cloud server and receive a vector generation method fed back by the cloud server. Optionally, the behavior vector may be generated by a method pre-installed in the terminal.

S106, if the operation of triggering the instrumentation code is a risk operation, sending the identification of the fast application and a judgment result to a cloud server;

the determination result may be indication information for indicating the classification of the fast application. For example, the application can be a low-risk malicious application and a high-risk malicious application. Accordingly, the cloud server stores the processing policy for each type of fast application. For example, high-risk malicious applications are directly off-shelf; for example, a low risk malicious application halts the service and needs to reconfirm the risk.

S107, receiving a detection message fed back by the terminal, wherein the detection message comprises a quick application identifier and a detection result;

and S108, if the detection result indicates that the fast application corresponding to the fast application identifier has risk operation, processing the fast application corresponding to the fast application identifier according to a preset strategy.

Optionally, after the sending the detection model to the terminal, the method further includes: receiving operation data fed back by the terminal; updating the detection model by using the operation data fed back by the terminal; and feeding back the updated detection model to the terminal. Correspondingly, when the update message sent by the cloud server is received, the terminal updates the detection model stored before by using the target detection model in the received update message.

Referring to fig. 5, fig. 5 is a flowchart illustrating a method for detecting malicious fast applications according to an embodiment of the present invention. As shown in fig. 5, a method for detecting a malicious fast application according to an embodiment of the present invention includes the following steps:

s201, a cloud server receives a behavior log fed back by a fast application engine; performing model training according to the behavior log to obtain a detection model; and sending the detection model to a terminal;

when it is required to be pointed out, the cloud server may be deployed in a centralized manner or in a distributed manner, and the deployment manner of the cloud server is not limited again. In addition, the method for acquiring the detection model by the cloud server may refer to the method described in fig. 2, and details are not repeated here.

Specifically, the cloud server may convert the behavior log into a behavior vector according to a preset method, and train the behavior vector by using a preset machine learning algorithm to obtain the detection model. The preset machine learning algorithm may be a supervised learning algorithm, a bayesian learning algorithm, a classification learning algorithm, etc., which are not listed herein.

It is to be understood that the cloud server may transmit the detection model to a plurality of terminals. It is understood that, for example, if the terminal is registered on the cloud server, the cloud server sends the detection model to the registered terminal.

S202, the cloud server receives operation data fed back by the terminal; updating the detection model by using the operation data fed back by the terminal; feeding back the updated detection model to the terminal;

it can be understood that the cloud server receives the result fed back by each terminal in real time. And then, updating the detection model according to the received result every preset time period, and pushing the updated model to the terminal.

S203, when an updating message sent by the cloud server is received, the terminal updates the detection model stored before by using the target detection model in the received updating message;

s204, when the instrumentation code is detected to be triggered, the terminal determines whether an Application Programming Interface (API) corresponding to the instrumentation code is a target API or not according to a triggering strategy;

In addition, optionally, the method further includes generating a log of the target application program according to a call record of the target API when the instrumentation code is detected to be triggered. Wherein the log comprises a fast application identifier, a behavior parameter, and a trigger time.

S205, if the API corresponding to the instrumentation code is a target API, the terminal acquires a log for calling a fast application of the target API;

for example, if the API corresponding to the instrumentation code is the target API, that is, it is determined that the behavior needs to be detected according to the trigger policy, all logs of the fast application are taken out from the logs.

S206, the terminal generates a behavior vector according to the fast application log; matching the behavior vector with the detection model; and judging whether the operation of triggering the instrumentation code is risk operation or not according to the matching result.

S207, if the operation of triggering the instrumentation code is a risk operation, the terminal sends the identification of the fast application and a judgment result to a cloud server;

And S208, if the detection result indicates that the fast application corresponding to the fast application identifier has risk operation, the cloud server processes the fast application corresponding to the fast application identifier according to a preset strategy.

According to the scheme of the embodiment of the invention, after the cloud server trains the detection model according to the mass data, the detection model is updated according to the operation data fed back by each terminal, and the terminal identifies the malicious fast application according to the updated detection model, so that the cloud server is promoted to process the malicious fast application, and the malicious fast application is prevented from hurting the user.

Referring to fig. 6, fig. 6 is a schematic structural diagram of a terminal according to an embodiment of the present invention. As shown in fig. 6, an embodiment of the present invention provides a terminal 300, where the terminal may be a smart phone, a tablet computer, an intelligent wearable device, and other devices. The terminal 300 includes:

a determining unit 301, configured to determine, when it is detected that an instrumentation code is triggered, whether an application programming interface API corresponding to the instrumentation code is a target API according to a trigger policy;

an obtaining unit 302, configured to obtain a log of a fast application calling a target API if the API corresponding to the instrumentation code is the target API;

a judging unit 303, configured to judge whether an operation that triggers the instrumentation code is a risk operation according to the fast application log and a detection model;

a sending unit 304, configured to send the identifier of the fast application and the determination result to a cloud server if the operation that triggers the instrumentation code is a risk operation.

Optionally, the determining unit 303 is specifically configured to: generating a behavior vector according to the log of the fast application; matching the behavior vector with the detection model; and judging whether the operation of triggering the instrumentation code is risk operation or not according to the matching result.

Optionally, the terminal 300 further includes a receiving unit and a storage unit;

the receiving unit is used for receiving the detection model sent by the cloud server;

the storage unit is used for storing the detection model.

Optionally, the terminal 300 further includes an updating unit;

and the updating unit is used for updating the detection model stored before by using the target detection model in the received update message when the update message sent by the cloud server is received.

Optionally, the terminal 300 further includes a generating unit;

and the generating unit is used for generating a log of the target application program according to the call record of the target API when the instrumentation code is detected to be triggered.

In addition, it is noted that the log includes a fast application identification, a behavior parameter, and a trigger time.

The logic unit may be configured to execute steps corresponding to the terminal in fig. 4 or fig. 5, and details of the method are described in fig. 4 or fig. 5, which are not described herein again.

Referring to fig. 7, fig. 7 is a schematic structural diagram of a cloud server according to an embodiment of the present invention. As shown in fig. 7, an embodiment of the present invention provides a cloud server 400, where. The cloud server 400 includes:

an obtaining unit 401, configured to obtain historical operating data of a fast application;

a training unit 402, configured to train the historical operating data by using a machine learning algorithm to obtain a detection model;

a sending unit 403, configured to send the detection model to a terminal.

Optionally, the cloud server 400 further includes a first receiving unit and a processing unit:

the first receiving unit is configured to receive a detection message fed back by the terminal, where the detection message includes a fast application identifier and a detection result;

and the processing unit is used for processing the fast application corresponding to the fast application identifier according to a preset strategy if the detection result indicates that the fast application corresponding to the fast application identifier has risk operation.

Optionally, the cloud server 400 further includes a second receiving unit and an updating unit;

the second receiving unit is configured to receive the operation data fed back by the terminal;

the updating unit is used for updating the detection model by using the operation data fed back by the terminal;

the sending unit is further configured to feed back the updated detection model to the terminal.

The logic unit may be configured to execute steps corresponding to the cloud server in fig. 4 or fig. 5, and the detailed description is given in fig. 4 or fig. 5 for the description of the method, which is not described herein again.

Referring to fig. 8, in another embodiment of the present invention, a terminal is provided. The terminal 500 includes hardware such as a CPU501, a memory 502, a bus 503, and a display 504. The terminal 500 may be a smart phone, a tablet computer, an intelligent wearable device, or the like.

The CPU501 executes a program pre-stored in the memory 502, and the execution process specifically includes:

Optionally, the determining, according to the log of the fast application and the detection model, whether an operation that triggers the instrumentation code is a risk operation includes:

generating a behavior vector according to the log of the fast application;

matching the behavior vector with the detection model;

and judging whether the operation of triggering the instrumentation code is risk operation or not according to the matching result.

Optionally, before determining, according to the log of the fast application and the detection model, whether an operation that triggers the instrumentation code is a risk operation, the executing process further includes:

receiving the detection model sent by the cloud server;

and storing the detection model.

Optionally, the executing process further includes:

when an updating message sent by the cloud server is received, the detection model stored before is updated by using the target detection model in the received updating message.

Optionally, the executing process further includes:

and when detecting that the instrumentation code is triggered, generating a log of the target application program according to the call record of the target API.

Optionally, the log includes a fast application identifier, a behavior parameter, and a trigger time.

In addition, it should be noted that the physical structure of the cloud server is also shown in fig. 8. That is, the physical structure provided in fig. 8 may also perform the steps corresponding to the cloud server in fig. 4 or fig. 5.

Referring to fig. 9, fig. 9 is a block diagram of a mobile phone part structure related to a terminal according to an embodiment of the present invention. Referring to fig. 9, the handset includes: radio Frequency (RF) circuit 610, memory 620, input unit 630, display unit 640, sensor 650, audio circuit 660, Wireless Fidelity (WiFi) module 670, processor 680, and power supply 690. Those skilled in the art will appreciate that the handset configuration shown in fig. 9 is not intended to be limiting and may include more or fewer components than those shown, or some components may be combined, or a different arrangement of components.

The following describes each component of the mobile phone in detail with reference to fig. 9:

the RF circuitry 610 may be used for the reception and transmission of information. In general, RF circuit 610 includes, but is not limited to, an antenna, at least one Amplifier, a transceiver, a coupler, a Low Noise Amplifier (LNA), a duplexer, and the like. In addition, the RF circuitry 610 may also communicate with networks and other devices via wireless communications. The wireless communication may use any communication standard or protocol, including but not limited to Global System for Mobile communication (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), email, Short Messaging Service (SMS), and the like.

The memory 620 may be used to store software programs and modules, and the processor 610 executes various functional applications and data processing of the mobile phone by operating the software programs and modules stored in the memory 620. The memory 620 may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required by at least one function (such as a wi-fi network connection function, a positioning function, a polling policy making function, etc.), and the like; the storage data area may store data created according to the usage of the mobile phone (such as a user Wi-Fi usage record, etc.), and the like. Further, the memory 620 may include high speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid state storage device.

The input unit 630 may be used to receive input numeric or character information and generate key signal inputs related to user settings and function control of the cellular phone. Specifically, the input unit 630 may include a fingerprint recognition module 931 and other input devices 632. Fingerprint identification module 631 can gather the fingerprint data of user above it. Optionally, the fingerprint recognition module 631 may include an optical fingerprint module, a capacitive fingerprint module, and a radio frequency fingerprint module. Taking the fingerprint recognition module 631 as an example of a capacitive fingerprint recognition module, the fingerprint recognition module specifically includes sensing electrodes (n1 abnormal sensing electrodes and n2 normal sensing electrodes) and a signal processing circuit (such as an amplifying circuit, a noise suppression circuit, an analog-to-digital conversion circuit, etc.) connected to the sensing electrodes. In addition to the fingerprint recognition module 631, the input unit 630 may further include other input devices 932. In particular, other input devices 632 may include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, a mouse, a joystick, and the like.

The display unit 640 may be used to display information input by the user or information provided to the user and various menus of the mobile phone. The Display unit 640 may include a Display screen 641, and optionally, the Display screen 641 may be configured in the form of a Liquid Crystal Display (LCD), an Organic Light-Emitting Diode (OLED), or the like. Although in fig. 9, the fingerprint identification module 631 and the display 641 are two independent components to implement the input and output functions of the mobile phone, in some embodiments, the fingerprint identification module 631 and the display 641 may be integrated to implement the input and output functions of the mobile phone.

The handset may also include at least one sensor 650, such as a light sensor, motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor that adjusts the brightness of the display 641 according to the brightness of ambient light, and a proximity sensor that turns off the display 641 and/or the backlight when the mobile phone is moved to the ear. As one of the motion sensors, the accelerometer sensor can detect the magnitude of acceleration in each direction (generally, three axes), can detect the magnitude and direction of gravity when stationary, and can be used for applications of recognizing the posture of a mobile phone (such as horizontal and vertical screen switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer and tapping), and the like; as for other sensors such as a gyroscope, a barometer, a hygrometer, a thermometer, and an infrared sensor, which can be configured on the mobile phone, further description is omitted here.

Audio circuit 660, speaker 661, and microphone 662 can provide an audio interface between a user and a cell phone. The audio circuit 660 may transmit the electrical signal converted from the received audio data to the speaker 661, and convert the electrical signal into an audio signal through the speaker 661 for output; on the other hand, the microphone 662 converts the collected sound signals into electrical signals, which are received by the audio circuit 990 and converted into audio data, which are then processed by the audio data output processor 680 and sent via the RF circuit 610 to, for example, another cellular phone, or output to the memory 620 for further processing.

WiFi belongs to short-distance wireless transmission technology, and the mobile phone can help a user to receive and send e-mails, browse webpages, access streaming media and the like through the WiFi module 670, and provides wireless broadband Internet access for the user. Although fig. 9 shows the WiFi module 670, it is understood that it does not belong to the essential constitution of the handset, and can be omitted entirely as needed within the scope not changing the essence of the invention.

The processor 680 is a control center of the mobile phone, and connects various parts of the entire mobile phone by using various interfaces and lines, and performs various functions of the mobile phone and processes data by operating or executing software programs and/or modules stored in the memory 620 and calling data stored in the memory 620, thereby performing overall monitoring of the mobile phone. Optionally, processor 680 may include one or more processing units; preferably, the processor 980 may integrate an application processor, which primarily handles operating systems, user interfaces, applications, etc., and a modem processor, which primarily handles wireless communications. It will be appreciated that the modem processor described above may not be integrated into processor 680.

The handset also includes a power supply 690 (e.g., a battery) for powering the various components, which may preferably be logically connected to the processor 680 via a power management system, such that the power management system may be used to manage charging, discharging, and power consumption.

Although not shown, the mobile phone may further include a camera, a bluetooth module, etc., which are not described herein.

In the embodiments shown in fig. 4 or fig. 5, the method flows of the steps corresponding to the terminal may be implemented based on the structure of the mobile phone.

In the foregoing embodiments, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus may be implemented in other manners. For example, the above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one type of division of logical functions, and there may be other divisions when actually implementing, for example, a plurality of units or components may be combined or may be integrated into another system, or some features may be omitted, or not implemented. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection of some interfaces, devices or units, and may be an electric or other form.

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

In addition, functional units in the embodiments of the present invention may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present invention may be embodied in the form of a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: a U-disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a removable hard disk, a magnetic or optical disk, and other various media capable of storing program codes.

The above-mentioned embodiments are only used for illustrating the technical solutions of the present invention, and not for limiting the same; although the present invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present invention.

Claims

A method for detecting malicious fast applications, the method comprising:

when detecting that the instrumentation code is triggered, determining whether a fast Application Programming Interface (API) corresponding to the instrumentation code is a target API or not according to a triggering strategy;

if the API corresponding to the instrumentation code is a target API, acquiring a log of a fast application calling the target API;

judging whether the operation of triggering the instrumentation code is a risk operation or not according to the log of the fast application and a detection model;

and if the operation of triggering the instrumentation code is a risk operation, sending the identification of the fast application and a judgment result to a cloud server.
The method of claim 1, wherein determining whether the operation that triggers the instrumentation code is a risk operation according to the log of the fast application and a detection model comprises:

generating a behavior vector according to the log of the fast application;

matching the behavior vector with the detection model;

and judging whether the operation of triggering the instrumentation code is risk operation or not according to the matching result.
The method of claim 2, wherein before determining whether the operation that triggered the instrumented code is a risky operation based on the log of fast applications and a detection model, the method further comprises:

receiving the detection model sent by the cloud server;

and storing the detection model.
The method of claim 3, further comprising:

when an updating message sent by the cloud server is received, the detection model stored before is updated by using the target detection model in the received updating message.
The method of claim 4, further comprising:

and when detecting that the instrumentation code is triggered, generating a log of the target application program according to the call record of the target API.
The method of claim 5, wherein the log comprises a fast application identification, a behavior parameter, and a trigger time.
A method for acquiring a detection model is characterized by comprising the following steps:

acquiring historical operating data of the fast application;

training the historical operating data by using a machine learning algorithm to obtain a detection model;

and sending the detection model to a terminal.
The method of claim 7, wherein after sending the detection model to the terminal, the method further comprises:

receiving a detection message fed back by the terminal, wherein the detection message comprises a quick application identifier and a detection result;

and if the detection result indicates that the fast application corresponding to the fast application identifier has risk operation, processing the fast application corresponding to the fast application identifier according to a preset strategy.
The method according to claim 7 or 8, wherein after the sending of the detection model to the terminal, the method further comprises:

receiving operation data fed back by the terminal;

updating the detection model by using the operation data fed back by the terminal;

and feeding back the updated detection model to the terminal.
A terminal, characterized in that the terminal comprises:

the device comprises a determining unit, a judging unit and a judging unit, wherein the determining unit is used for determining whether an Application Programming Interface (API) corresponding to an instrumentation code is a target API or not according to a triggering strategy when the instrumentation code is detected to be triggered;

the acquiring unit is used for acquiring a log of a fast application calling the target API if the API corresponding to the instrumentation code is the target API;

the judging unit is used for judging whether the operation of triggering the instrumentation code is a risk operation or not according to the log of the fast application and a detection model;

and the sending unit is used for sending the identifier of the fast application and the judgment result to a cloud server if the operation of triggering the instrumentation code is a risk operation.
The terminal according to claim 10, wherein the determining unit is specifically configured to:

generating a behavior vector according to the log of the fast application;

matching the behavior vector with the detection model;

and judging whether the operation of triggering the instrumentation code is risk operation or not according to the matching result.
The terminal according to claim 11, characterized in that the terminal further comprises a receiving unit and a storing unit;

the receiving unit is used for receiving the detection model sent by the cloud server;

the storage unit is used for storing the detection model.
The terminal according to claim 12, characterized in that the terminal further comprises an updating unit;

and the updating unit is used for updating the detection model stored before by using the target detection model in the received updating message when the updating message sent by the cloud server is received.
The terminal according to claim 13, characterized in that the terminal further comprises a generating unit;

and the generating unit is used for generating a log of the target application program according to the call record of the target API when the instrumentation code is detected to be triggered.
The terminal of claim 14, wherein the log comprises a fast application identification, a behavior parameter, and a trigger time.
A cloud server, the cloud server comprising:

the acquisition unit is used for acquiring historical operating data of the fast application;

the training unit is used for training the historical operating data by utilizing a machine learning algorithm to obtain a detection model;

and the sending unit is used for sending the detection model to the terminal.
The cloud server of claim 16, wherein the cloud server further comprises a first receiving unit and a processing unit:

the first receiving unit is configured to receive a detection message fed back by the terminal, where the detection message includes a fast application identifier and a detection result;

and the processing unit is used for processing the fast application corresponding to the fast application identifier according to a preset strategy if the detection result indicates that the fast application corresponding to the fast application identifier has risk operation.
The cloud server according to claim 16 or 17, wherein the cloud server further comprises a second receiving unit and an updating unit;

the second receiving unit is configured to receive the operation data fed back by the terminal;

the updating unit is used for updating the detection model by using the operation data fed back by the terminal;

the sending unit is further configured to feed back the updated detection model to the terminal.