WO2020232685A1

WO2020232685A1 - Malicious quickapp detection method and terminal

Info

Publication number: WO2020232685A1
Application number: PCT/CN2019/088038
Authority: WO
Inventors: 郭子亮
Original assignee: 深圳市欢太科技有限公司; Oppo广东移动通信有限公司
Priority date: 2019-05-22
Filing date: 2019-05-22
Publication date: 2020-11-26
Also published as: CN113366477A

Abstract

The present invention provides a malicious quickapp detection method and a terminal. The method comprises: if it is detected that an instrumentation code is triggered, determining whether the application programming interface (API) corresponding to the instrumentation code is a target API according to a trigger policy; if the API corresponding to the instrumentation code is the target API, obtaining the log of a quickapp calling the target API; determining, according to the log of the quickapp and a detection model, whether the operation of triggering the instrumentation code is a risky operation; if the operation of triggering the instrumentation code is the risky operation, sending the identifier of the quickapp and the determination result to a cloud server. Therefore, by collecting logs during running in real time to study and determine the maliciousness of quickapps, a malicious quickapp can be quickly determined, thereby promoting the cloud server to handle the malicious quickapp to prevent the malicious quickapp from harming users.

Description

Method and terminal for detecting malicious quick application

Technical field

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

Background technique

Quick application (quickapp) is a new application form based on the mobile phone hardware platform. Users do not need to download and install, click to use, and enjoy the performance experience of native applications. At present, with the development of fast apps, more and more fast apps appear in people's lives, such as QR code and ride fast apps, WeChat ordering fast apps, etc.

At present, fast apps developed based on terminals are reviewed (manually run or machine scanned rpk files) before they are released, and fast apps will be put on the shelves after the approval is passed, and fast apps that fail the review will not be put on the shelves. However, technologies that are only reviewed before release can easily be bypassed by malicious developers' anti-virus technologies, causing harm to users.

Summary of the invention

The embodiment of the present invention provides a method and terminal for detecting malicious quick applications, which conducts malicious research and judgment of quick applications by collecting application logs in real time, and has extremely strong anti-anti-anti-kill ability and improves user experience.

The first aspect of the embodiments of the present invention discloses a method for detecting malicious quick applications, and the method includes:

When it is detected that the instrumentation code is triggered, determine whether the application programming interface API corresponding to the instrumentation code is the target API according to the trigger strategy;

If the API corresponding to the instrumentation code is the target API, obtain the log of the fast application that calls the target API;

Determine whether the operation that triggers the instrumentation code is a risk operation according to the log of the quick application and the detection model;

If the operation that triggers the instrumentation code is a risk operation, the identification of the fast application and the judgment result are sent to the cloud server.

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

Get the historical operating data of the fast application;

Using a machine learning algorithm to train the historical operating data to obtain a detection model;

Send the detection model to the terminal.

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

The determining unit is configured to determine whether the application programming interface API corresponding to the instrumentation code is the target API according to the trigger strategy when it is detected that the instrumentation code is triggered;

An obtaining unit, configured to obtain a log of the fast application that calls the target API if the API corresponding to the instrumentation code is the target API;

The judging unit is configured to judge whether the operation that triggers the instrumentation code is a risk operation according to the log of the quick application and the detection model;

The sending unit is configured to send the identification of the fast application and the judgment result to the cloud server if the operation that triggers the instrumentation code is a risk operation.

The fourth aspect of the present invention discloses a cloud server, which includes:

The acquisition unit is used to acquire historical operating data of fast applications;

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

The sending unit is used to send the detection model to the terminal.

The fifth aspect of the present invention discloses a storage medium in which a program is stored; when the program is executed, the processor executes the method described in the first aspect or the second aspect.

A sixth aspect of the present invention discloses a terminal. The terminal includes a processor and a memory; a program is stored in the memory; when the program is run, the processor executes the method described in the first aspect.

It can be seen that in the solution of the embodiment of the present invention, when it is detected that the instrumentation code is triggered, it is determined according to the trigger strategy whether the application call interface API corresponding to the instrumentation code is the target API; if the instrumentation code corresponds to If the API of is the target API, obtain the log of the quick application that called the target API; determine whether the operation that triggered the instrumentation code is a risk operation according to the log of the quick application and the detection model; if the instrumentation code is triggered If the operation is a risk operation, the identification of the fast application and the judgment result are sent to the cloud server. Therefore, it can be seen that by collecting runtime logs in real time to conduct malicious research and judgment of fast applications, malicious fast applications can be quickly determined, and the cloud server can be pushed to process the malicious fast applications to prevent malicious fast applications from harming users.

Description of the drawings

In order to more clearly describe the technical solutions in the embodiments of the present invention, the following will briefly introduce the drawings needed in the embodiments. Obviously, the drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, without creative work, other drawings can be obtained from these drawings.

FIG. 1 is a schematic diagram of the architecture of a malicious fast application detection system provided by an embodiment of the present invention;

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

3 is a schematic flowchart of a method for detecting malicious fast applications according to an embodiment of the present invention;

4 is a schematic flowchart of another method for detecting malicious fast applications according to an embodiment of the present invention;

FIG. 5 is a schematic flowchart of another method for detecting malicious fast applications according to an embodiment of the present invention;

FIG. 6 is a schematic structural diagram of a terminal provided by an embodiment of the present invention;

FIG. 7 is a schematic structural diagram of a cloud server provided by an embodiment of the present invention;

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

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

Detailed ways

The embodiment of the present invention provides a method and terminal for detecting malicious quick applications, which can quickly identify malicious quick applications, and promote the cloud server to process the malicious quick applications to prevent the malicious quick applications from harming users.

In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are the present invention. Part of the embodiment, not all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative work shall fall within the protection scope of the present invention.

The terms "first", "second" and "third" appearing in the specification, claims, and drawings of the present invention are used to distinguish different objects, rather than describing a specific sequence. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but optionally includes unlisted steps or units, or optionally also includes Other steps or units inherent to these processes, methods, products or equipment.

In addition, the following terms may be used in the following embodiments of the present invention, and the following terms are explained here.

Quick application (quickapp): is a new application form based on the mobile phone hardware platform. Users do not need to download and install, click to use, and enjoy the performance experience of native applications. The fast application framework is deeply integrated into the mobile phone systems of various manufacturers, which can realize seamless connection between user needs and application services at the operating system level, improve user experience and application service conversion efficiency, and support the generation of desktop icons and other retention capabilities.

rpk file: The file generated after the fast application source code and resources are compiled and packaged. In fact, it is the final output obtained by packaging and compressing the resources required by the fast application runtime into a file, and signing the compressed file, similar to the Android APK file ( AndroidPackage, Android installation package).

Malicious fast apps: fast apps that usually bring losses to users' interests without the user's knowledge.

Fast application engine: Provides the rpk file operating environment, which is essentially an APK, and provides a series of interfaces (API) for rpk.

Quick Application API (Application Programming Interface): The interface provided by the Quick Application Engine for developers.

Anti-Virus: It is the opposite of Anti-Virus and Anti-Spyware. The English name is Anti-AntiVirus, which translates to "Anti-Virus Technology". It is a technology that enables virus Trojans to avoid being checked and killed by anti-virus software. Virus-free refers to virus files that have been processed by the technology of virus-free. The anti-kill in the present invention mainly refers to the technology used by malicious quick application developers to evade or bypass the quick application platform audit mechanism.

Monkey emulator: A stress testing software provided by Google for Android application developers. It tests the stress resistance of applications in high-stress environments by randomly generating user touches and keyboard operations. This article uses it to simulate ordinary users enter.

Instrumentation: Insert a piece of custom code into the code, and the custom code will be executed during the running of the program.

In one embodiment of the present invention, a malicious quick application detection system deployed in a terminal is disclosed, which can respond to detection in a timely manner and has extremely strong anti-anti-killing ability, so that malicious quick applications can be discovered and dealt with in a timely manner to avoid Cause harm to users.

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

In the cloud, the model training module is responsible for training and generating a detection model or virus library from massive data, and sending it to the terminal for use; the result processing module is responsible for receiving the detection results reported by the terminal, and removing malicious quick applications.

In the terminal, the event monitor is pre-embedded in the fast application engine, and insert stubs at each API of the fast application engine. When an application is running on the terminal, the instrumentation code buried in each API is triggered, and the API call is recorded Become a log; the vector generator is responsible for cleaning the log and generating the vectors needed for detection; the analysis determiner classifies the vector according to the model issued by the cloud to determine whether the fast application is malicious, and reports the result to the cloud for disposal .

In terms of process, this program mainly includes model training process and testing process:

The training process shown in Figure 2. The model training is completed in the cloud. The workflow of this part is as follows:

1) Select a batch of training samples (RPK files) with labels (indicate what kind of risky behavior this sample carries).

2) Push the samples one by one to the fast application engine, which has been pre-instrumented at each API.

3) Use tools such as Monkey to randomly simulate user operations.

4) At this time, the fast application API will be triggered. At this time, we will run the instrumentation code we defined. Our instrumentation code only needs to record this API call and output a log, and then return to the original API call address , Complete the API call. The log contains at least four fields: quick app identification (mark which quick app triggered this log), behavior id (the ID of the API triggered by the quick app), behavior parameters (the parameters of the API triggered by the quick app), Trigger time (the time this API was triggered).

5) After the program runs for a period of time, we can get a behavior sequence. We convert the behavior sequence into a behavior vector. There are many conversion methods, for example: sort according to the increase of trigger time, and directly compose all behavior ids (numbers) a string of numbers. Or use a preset keyword library to match behavior parameters, and use the number of hits to generate vectors.

6) Repeat the above process until the behavior vectors of all training set samples are obtained. Input the behavior vector and its corresponding sample label (what kind of risk behavior) into the training program to train, and finally get a model file. There are many choices for the training algorithm here, such as LSTM (Long Short-Term Memory) and so on.

The detection process shown in Figure 3, the detection part is carried out on the terminal, the work flow of this part is as follows:

1) When the instrumentation code is triggered, first record the API call to become a log. The log contains at least four fields: quick app ID, behavior id, behavior parameter, and trigger time (the meaning of the fields is the same as in the training process) . Then return to the original API call address to complete the API call. The following processes are all performed asynchronously without blocking the API call.

2) Match the preset trigger strategy to determine whether detection is needed. This is because we have more instrumentation points. If each API is triggered, a detection is performed, which will have a greater impact on performance. The trigger strategy can be customized according to the actual situation. For example, if we are more concerned about malicious deductions, then we can define a detection to be triggered every time the SMS API is triggered.

3) If the trigger strategy determines that this behavior needs to be detected, all logs of this fast application will be taken from the logs to generate behavior vectors (the generation method must be consistent with the vector generation method in the training phase). Use behavior vector to call analysis and judgment module.

4) The analysis and judgment module uses the received behavior vector and the pre-loaded model file to call the prediction program of the model to determine the behavior vector.

5) If the judgment result shows that the behavior is risky, the quick application identification and detection result are reported to the cloud, and the cloud will handle it.

Through the methods provided in Figures 2 and 3, a batch of detection points can be preset in the fast application engine of the terminal to collect the running logs of the fast application, and the fast application can be researched and judged based on the generated log and detection model to detect whether the fast application is Malicious, and send the identification and detection result of the malicious quick application to the cloud for disposal (for example, the cloud can remove the malicious quick application from the shelves, etc.). The cloud uses the collected massive samples and behavioral data to train the detection model and send it to the terminal. In addition, the terminal can continuously receive the updated model issued by the cloud, thereby having the ability to continuously detect malicious fast applications.

Please refer to FIG. 4, which is a schematic flowchart of a method for detecting malicious fast applications according to an embodiment of the present invention. Wherein, as shown in FIG. 4, a method for detecting malicious fast applications provided by an embodiment of the present invention includes the following content:

S101. The cloud server obtains historical operation data of the fast application; uses a machine learning algorithm to train the historical operation data to obtain a detection model; and sends the detection model to a terminal;

Among them, when it needs to be pointed out, the cloud server can be deployed in a centralized manner or in a distributed manner. The deployment method of the cloud server is not limited here. In addition, the method for obtaining the detection model by the cloud server can refer to the method described in FIG. 2, which will not be 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 smart phone, a tablet computer, a smart wearable device, and a computer.

S103: When it is detected that the instrumentation code is triggered, determine whether the application programming interface API corresponding to the instrumentation code is the target API according to the trigger strategy;

Among them, what needs to be pointed out is that API can be instrumented according to requirements; all APIs can also be instrumented.

In addition, it is understandable that if there are many APIs for instrumentation, the target API needs to be set for targeted detection. For example, the target API can be an API for payment, such as an API for extracting private information.

In addition, it needs to be pointed out that there are more instrumentation points in the case. If each API is triggered, it will be tested once, which will have a greater impact on performance. Optionally, the trigger strategy can be customized according to the actual situation. For example, if we are more concerned about malicious deductions, then we can define a detection to be triggered every time the SMS API is triggered.

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

Among them, it is understandable that the instrumentation code is triggered, and the instrumentation code of the target API is executed soon, and the instrumentation code generates a log of the target application according to the call record of the target API, and then returns to the call of the target API Address, complete the target API call. Wherein, the log includes quick application identification, behavior identification, behavior parameter, and trigger time.

S104: If the API corresponding to the instrumentation code is the target API, obtain a log of the fast application that calls 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 strategy, then all logs of this fast application will be taken from the logs.

S105: Determine whether the operation that triggers the instrumentation code is a risk operation according to the log of the quick application and the detection model;

Optionally, the judging whether the operation that triggers the instrumentation code is a risk operation according to the log of the fast application and the detection model includes: generating a behavior vector according to the log of the fast application; and comparing the behavior vector with the detection model The model is matched; according to the matching result, it is judged whether the operation that triggers the instrumentation code is a risk operation.

Among them, it should be pointed out that the method of generating behavior vectors must be consistent with the vector generation method in the training phase. Therefore, the terminal may send a vector generation method acquisition request to the cloud server, and receive the vector generation method fed back by the cloud server. Optionally, the method for generating the behavior vector may also be pre-installed on the terminal.

S106: If the operation that triggers the instrumentation code is a risk operation, send the identification of the fast application and the judgment result to the cloud server;

Wherein, the judgment result may be indication information used to indicate the classification of the fast application. For example, it can be low-risk malicious applications and high-risk malicious applications. Correspondingly, the cloud server will store the processing strategy of each type of fast application. For example, high-risk malicious applications will be removed directly; for example, low-risk malicious applications will suspend their services and need to reconfirm the risks.

S107. Receive a detection message fed back by the terminal, where the detection message includes a quick application identifier and a detection result.

S108. If the detection result indicates that the fast application corresponding to the fast application identifier has a risky operation, the fast application corresponding to the fast application identifier is processed according to a preset strategy.

Optionally, after the sending of the detection model to the terminal, the method further includes: receiving operating data fed back by the terminal; updating the detection model using the operating data fed back by the terminal; and feeding back the update to the terminal After the detection model. Correspondingly, when receiving the update message sent by the cloud server, the terminal uses the target detection model in the received update message to update the previously stored detection model.

Please refer to FIG. 5, which is a schematic flowchart of a method for detecting malicious fast applications according to an embodiment of the present invention. Wherein, as shown in FIG. 5, a method for detecting malicious fast applications provided by an embodiment of the present invention includes the following contents:

S201: The cloud server receives the behavior log fed back by the fast application engine; performs model training according to the behavior log to obtain a detection model; and sends the detection model to the terminal;

Among them, when it needs to be pointed out, the cloud server can be deployed in a centralized or distributed manner, and the deployment mode of the cloud server is not limited again. In addition, the method for obtaining the detection model by the cloud server can refer to the method described in FIG. 2, which will not be repeated here.

Specifically, the cloud server may convert the behavior log into a behavior vector according to a preset method, and use a preset machine learning algorithm to train the behavior vector to obtain a detection model. Wherein, the preset machine learning algorithm may be a supervised learning algorithm, a Bayesian learning algorithm, a classification learning algorithm, etc., which are not listed here.

It is understandable that the cloud server may send the detection model to multiple terminals. It is understandable that, for example, if the terminal is registered on the cloud server, the cloud server will send the detection model to the registered terminal.

S202: The cloud server receives the operating data fed back by the terminal; uses the operating data fed back by the terminal to update the detection model; and feeds back the updated detection model to the terminal;

It is understandable that the cloud server will receive the feedback results from each terminal in real time. Then, at each preset time period, the detection model is updated according to the received result, and the updated model is pushed to the terminal.

S203: When receiving the update message sent by the cloud server, the terminal uses the target detection model in the received update message to update the previously stored detection model;

S204: When it is detected that the instrumentation code is triggered, the terminal determines whether the application programming interface API corresponding to the instrumentation code is the target API according to the trigger strategy;

In addition, it needs to be pointed out that there are more stub points in the case. If each API is triggered, it will be tested once, which will have a greater impact on performance. Optionally, the trigger strategy can be customized according to the actual situation. For example, if we are more concerned about malicious deductions, then we can define a detection to be triggered every time the SMS API is triggered.

In addition, optionally, the method further includes: when it is detected that the instrumentation code is triggered, generating a log of the target application according to the call record of the target API. Wherein, the log includes quick application identification, behavior identification, behavior parameter, and trigger time.

S205: If the API corresponding to the instrumentation code is the target API, the terminal obtains the log of the quick application that calls 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 strategy, then all logs of this fast application are taken out of the logs.

S206. The terminal generates a behavior vector according to the log of the fast application; matches the behavior vector with the detection model; and determines whether the operation that triggers the instrumentation code is a risk operation according to the matching result.

S207: If the operation that triggers the instrumentation code is a risk operation, the terminal sends the identification of the fast application and the judgment result to the cloud server;

S208: If the detection result indicates that the fast application corresponding to the fast application identifier has a risky operation, the cloud server processes the fast application corresponding to the fast application identifier according to a preset strategy.

It can be seen that in the solution of the embodiment of the present invention, after the cloud server trains the detection model based on massive data, the detection model will be subsequently updated based on the operating data fed back by each terminal, and the terminal will perform malicious quick applications based on the updated detection model. In order to prevent the malicious quick application from harming users, the cloud server is further promoted to process the malicious quick application.

Please refer to FIG. 6, which is a schematic structural diagram of a terminal according to an embodiment of the present invention. Among them, as shown in FIG. 6, an embodiment of the present invention provides a terminal 300, where the terminal may be a device such as a smart phone, a tablet computer, or a smart wearable device. The terminal 300 includes:

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

The acquiring unit 302 is configured to, if the API corresponding to the instrumentation code is the target API, acquire the log of the quick application that calls the target API;

The judging unit 303 is configured to judge whether the operation that triggers the instrumentation code is a risk operation according to the log of the quick application and the detection model;

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

Optionally, the judgment unit 303 is specifically configured to: generate a behavior vector according to the log of the fast application; match the behavior vector with the detection model; determine whether the operation that triggers the instrumentation code is a risk according to the matching result operating.

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

The receiving unit is configured to receive the detection model sent by the cloud server;

The storage unit is used to store the detection model.

Optionally, the terminal 300 further includes an update unit;

The update unit is configured to use the target detection model in the received update message to update the previously stored detection model when an update message sent by the cloud server is received.

Optionally, the terminal 300 further includes a generating unit;

The generating unit is configured to generate a log of the target application program according to the call record of the target API when it is detected that the instrumentation code is triggered.

In addition, it should be pointed out that the log includes quick application identification, behavior identification, behavior parameters, and trigger time.

The above-mentioned logic unit may be used to execute the steps corresponding to the terminal in FIG. 4 or FIG. 5, and the specific description is shown in FIG. 4 or FIG. 5 for the description of the method, which will not be repeated here.

Please refer to FIG. 7, which is a schematic structural diagram of a cloud server provided by an embodiment of the present invention. Among them, as shown in FIG. 7, an embodiment of the present invention provides a cloud server 400, where. The cloud server 400 includes:

The acquiring unit 401 is configured to acquire historical operating data of the fast application;

The training unit 402 is configured to use a machine learning algorithm to train the historical operating data to obtain a detection model;

The sending unit 403 is configured to send the detection model to the 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, and the detection message includes a quick application identifier and a detection result;

The processing unit is configured to, if the detection result indicates that the fast application corresponding to the fast application identifier has risky operations, process the fast application corresponding to the fast application identifier according to a preset strategy.

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

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

The update unit is configured to update the detection model by using the operating data fed back by the terminal;

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

Wherein, the logic unit can be used to execute the steps corresponding to the cloud server in FIG. 4 or FIG. 5, and the specific description is shown in FIG. 4 or FIG. 5 for the description of the method, which will not be repeated here.

Referring to FIG. 8, in another embodiment of the present invention, a terminal is provided. The terminal 500 includes hardware such as a CPU 501, a memory 502, a bus 503, and a display screen 504. Wherein, the terminal 500 may be a device such as a smart phone, a tablet computer, or a smart wearable device.

Wherein, the CPU 501 executes a program pre-stored in the memory 502, and the execution process specifically includes:

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

Generate behavior vector according to the log of fast application;

Matching the behavior vector with the detection model;

Determine whether the operation that triggers the instrumentation code is a risk operation according to the matching result.

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

Receiving the detection model sent by the cloud server;

And store the detection model.

Optionally, the execution process further includes:

When an update message sent by the cloud server is received, the previously stored detection model is updated by using the target detection model in the received update message.

Optionally, the execution process further includes:

When it is detected that the instrumentation code is triggered, the log of the target application is generated according to the call record of the target API.

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

In addition, it should be pointed out that the physical structure of the cloud server is also shown in Figure 8. In other words, the physical structure provided in FIG. 8 can also perform the steps corresponding to the cloud server in FIG. 4 or FIG. 5.

Please refer to FIG. 9, which is a block diagram of a part of the structure of a mobile phone related to a terminal according to an embodiment of the present invention. Referring to FIG. 9, the mobile phone includes: a radio frequency (RF) circuit 610, a memory 620, an input unit 630, a display unit 640, a sensor 650, an audio circuit 660, a wireless fidelity (Wireless Fidelity, WiFi) module 670, and a processor 680 , And power supply 690 and other components. Those skilled in the art can understand that the structure of the mobile phone shown in FIG. 9 does not constitute a limitation on the mobile phone, and may include more or less components than those shown in the figure, or a combination of certain components, or different component arrangements.

The following is a detailed introduction to each component of the mobile phone in conjunction with Figure 9:

The RF circuit 610 can be used for receiving and transmitting information. Generally, the 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 circuit 610 can also communicate with the network and other devices through wireless communication. The above wireless communication can use any communication standard or protocol, including but not limited to Global System of Mobile Communication (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (Code Division) Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), E-mail, Short Messaging Service (SMS), etc.

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 running 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, where the storage program area may store an operating system and at least one application program required by a function (such as wi-fi network connection function, positioning function, polling strategy formulation function, etc.) Etc.; the data storage area can store data created based on the use of the mobile phone (such as user Wi-Fi usage records, etc.). In addition, the memory 620 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one magnetic disk storage device, a flash memory device, or other volatile solid-state storage devices.

The input unit 630 may be used to receive inputted digital or character information, and generate key signal input related to user settings and function control of the mobile phone. Specifically, the input unit 630 may include a fingerprint recognition module 931 and other input devices 632. The fingerprint identification module 631 can collect the fingerprint data of the user on it. Optionally, the fingerprint identification module 631 may include an optical fingerprint module, a capacitive fingerprint module, and a radio frequency fingerprint module. Taking the fingerprint identification module 631 as a capacitive fingerprint identification module as an example, it specifically includes sensing electrodes (n1 abnormal sensing electrodes and n2 normal sensing electrodes) and a signal processing circuit connected to the sensing electrodes (such as an amplifying circuit, noise Suppression circuit, analog-to-digital conversion circuit, etc.). In addition to the fingerprint recognition module 631, the input unit 630 may also include other input devices 932. Specifically, other input devices 632 may include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control buttons, switch buttons, etc.), trackball, mouse, 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. Optionally, the display screen 641 may be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), etc. Although in FIG. 9, the fingerprint identification module 631 and the display screen 641 are used as two independent components to realize the input and input functions of the mobile phone, in some embodiments, the fingerprint identification module 631 and the display screen 641 may be combined. Integrate to realize the input and output functions of the mobile phone.

The mobile phone may also include at least one sensor 650, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor. The ambient light sensor can adjust the brightness of the display 641 according to the brightness of the ambient light. The proximity sensor can turn off the display 641 and/or when the mobile phone is moved to the ear. Or backlight. As a kind of motion sensor, the accelerometer sensor can detect the magnitude of acceleration in various directions (usually three-axis), and can detect the magnitude and direction of gravity when stationary, and can be used to identify mobile phone posture applications (such as horizontal and vertical screen switching, related Games, magnetometer posture calibration), vibration recognition related functions (such as pedometer, percussion), etc.; as for other sensors such as gyroscopes, barometers, hygrometers, thermometers, infrared sensors, etc., which can be configured in mobile phones, we will not here Repeat.

The audio circuit 660, the speaker 661, and the microphone 662 can provide an audio interface between the user and the mobile phone. The audio circuit 660 can transmit the electric signal converted from the received audio data to the speaker 661, and the speaker 661 converts it into a sound signal for output; on the other hand, the microphone 662 converts the collected sound signal into an electric signal, and the audio circuit 990 After being received, it is converted into audio data, and then processed by the audio data output processor 680, and sent to, for example, another mobile phone via the RF circuit 610, or the audio data is output to the memory 620 for further processing.

WiFi is a short-distance wireless transmission technology. The mobile phone can help users send and receive emails, browse web pages, and access streaming media through the WiFi module 670. It provides users with wireless broadband Internet access. Although FIG. 9 shows the WiFi module 670, it is understandable that it is not a necessary component of the mobile phone and can be omitted as needed without changing the essence of the invention.

The processor 680 is the control center of the mobile phone. It uses various interfaces and lines to connect various parts of the entire mobile phone. It executes by running or executing software programs and/or modules stored in the memory 620, and calling data stored in the memory 620. Various functions and processing data of the mobile phone can be used to monitor the mobile phone as a whole. Optionally, the processor 680 may include one or more processing units; preferably, the processor 980 may integrate an application processor and a modem processor, where the application processor mainly processes the operating system, user interface, and application programs, etc. , The modem processor mainly deals with wireless communication. It can be understood that the foregoing modem processor may not be integrated into the processor 680.

The mobile phone also includes a power source 690 (such as a battery) for supplying power to various components. Preferably, the power source may be logically connected to the processor 680 through a power management system, so that functions such as charging, discharging, and power management are realized through the power management system.

Although not shown, the mobile phone may also include a camera, a Bluetooth module, etc., which will not be repeated here.

In the foregoing embodiment shown in FIG. 4 or FIG. 5, the method flow of each step corresponding to the terminal can be implemented based on the structure of the mobile phone.

In the above-mentioned embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in an embodiment, reference may be made to related descriptions of other embodiments.

In the several embodiments provided in this application, it should be understood that the disclosed device may be implemented in other ways. For example, the device embodiments described above are only illustrative. For example, the division of the units is only a logical function division, and there may be other divisions in actual implementation, for example, multiple units or components may be combined or may be Integrate into another system, or some features can be ignored or not implemented. In addition, the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, and may be in electrical or other forms.

The units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the objectives of the solutions of the embodiments.

In addition, the functional units in the various embodiments of the present invention may be integrated into one processing unit, or each unit may exist alone physically, or two or more units may be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or software functional unit.

If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer readable storage medium. Based on this understanding, the technical solution of the present invention essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium , Including several instructions to make a computer device (which may be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage media include: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic disk or optical disk and other media that can store program code .

As mentioned above, the above embodiments are only used to illustrate the technical solutions of the present invention, but not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: The technical solutions recorded in the embodiments are modified, or some of the technical features are equivalently replaced; these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

A method for detecting malicious quick applications, characterized in that the method includes:

When it is detected that the instrumentation code is triggered, determine whether the fast application programming interface API corresponding to the instrumentation code is the target API according to the trigger strategy;

If the API corresponding to the instrumentation code is the target API, obtain the log of the fast application that calls the target API;

Determine whether the operation that triggers the instrumentation code is a risk operation according to the log of the quick application and the detection model;

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

Generate behavior vector according to the log of fast application;

Matching the behavior vector with the detection model;

Determine whether the operation that triggers the instrumentation code is a risk operation according to the matching result.
The method according to claim 2, wherein before the judging whether the operation that triggers the instrumentation code is a risk operation according to the log of the fast application and the detection model, the method further comprises:

Receiving the detection model sent by the cloud server;

And store the detection model.
The method according to claim 3, wherein the method further comprises:

When an update message sent by the cloud server is received, the previously stored detection model is updated by using the target detection model in the received update message.
The method according to claim 4, wherein the method further comprises:

When it is detected that the instrumentation code is triggered, a log of the target application program is generated according to the call record of the target API.
The method according to claim 5, wherein the log includes a quick application identifier, a behavior identifier, a behavior parameter, and a trigger time.
A method for acquiring a detection model, characterized in that the method includes:

Get the historical operating data of the fast application;

Using a machine learning algorithm to train the historical operating data to obtain a detection model;

Send the detection model to the terminal.
The method according to claim 7, wherein after the sending the detection model to the terminal, the method further comprises:

Receiving a detection message fed back by the terminal, where the detection message includes a quick application identifier and a detection result;

If the detection result indicates that the fast application corresponding to the fast application identifier has risky operations, the fast application corresponding to the fast application identifier is processed according to a preset strategy.
The method according to claim 7 or 8, wherein after the sending the detection model to the terminal, the method further comprises:

Receiving operating data fed back by the terminal;

Update the detection model by using the operating data fed back by the terminal;

Feed back the updated detection model to the terminal.
A terminal, characterized in that the terminal includes:

The determining unit is configured to determine whether the application programming interface API corresponding to the instrumentation code is the target API according to the trigger strategy when it is detected that the instrumentation code is triggered;

An obtaining unit, configured to obtain a log of the fast application that calls the target API if the API corresponding to the instrumentation code is the target API;

The judging unit is configured to judge whether the operation that triggers the instrumentation code is a risk operation according to the log of the quick application and the detection model;

The sending unit is configured to send the identification of the fast application and the judgment result to the cloud server if the operation that triggers the instrumentation code is a risk operation.
The terminal according to claim 10, wherein the judging unit is specifically configured to:

Generate behavior vector according to the log of fast application;

Matching the behavior vector with the detection model;

Determine whether the operation that triggers the instrumentation code is a risk operation according to the matching result.
The terminal according to claim 11, wherein the terminal further comprises a receiving unit and a storage unit;

The receiving unit is configured to receive the detection model sent by the cloud server;

The storage unit is used to store the detection model.
The terminal according to claim 12, wherein the terminal further comprises an update unit;

The update unit is configured to use the target detection model in the received update message to update the previously stored detection model when an update message sent by the cloud server is received.
The terminal according to claim 13, wherein the terminal further comprises a generating unit;

The generating unit is configured to generate a log of the target application program according to the call record of the target API when it is detected that the instrumentation code is triggered.
The terminal according to claim 14, wherein the log includes a quick application identifier, a behavior identifier, a behavior parameter, and a trigger time.
A cloud server, characterized in that the cloud server includes:

The acquisition unit is used to acquire historical operating data of fast applications;

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

The sending unit is used to send 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, and the detection message includes a quick application identifier and a detection result;

The processing unit is configured to, if the detection result indicates that the fast application corresponding to the fast application identifier has risky operations, process the fast application corresponding to the fast application identifier according to a preset strategy.
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 operating data fed back by the terminal;

The update unit is configured to update the detection model by using the operating data fed back by the terminal;

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