A method, device and electronic equipment for risk reminding

Abstract

Embodiments of the present specification disclose a risk reminding method, device and electronic equipment. The risk reminding method comprises: acquiring a detection strategy for a non-pre-set application downloaded from a cloud server, the non-pre-set application being an application not downloaded through a pre-set download channel; in a case where a user performs a related behavior for a target non-pre-set application through a user terminal, performing a detection operation on related data of the target non-pre-set application according to the detection strategy; and in a case where a detection result indicates that the target non-pre-set application meets a risk application contained in the detection strategy, reminding the user of the risk application through the user terminal.

Description

Technical Field

[0001] This document belongs to the field of data processing technology, specifically relating to a method, device, and electronic equipment for risk alerts. Background Technology

[0002] In various online fraud scenarios, the illegal online industry often guides users to install various illegal and malicious applications on their devices. These illegal and malicious applications differ from viruses and Trojans, making them difficult for user terminal security software or antivirus engines to detect.

[0003] Current commonly used alert solutions for malicious applications primarily rely on web scraping to obtain their installation packages, then analyzing and identifying them on a cloud-based detection platform. Based on the cloud-based analysis, a risk alert is sent to the user's device. This approach is insufficient for effectively alerting users about malicious applications. Therefore, a superior risk alert solution is needed to address this specific need. Summary of the Invention

[0004] This specification provides a method, apparatus, and electronic device for risk alerts, thereby offering a risk alert solution.

[0005] In a first aspect, embodiments of this specification provide a method for risk alerts. The method includes: acquiring a detection strategy for non-preset applications downloaded from a cloud server, wherein the non-preset applications are those not downloaded through a preset download channel; when a user performs actions related to a target non-preset application through a user terminal, performing a risk application detection operation on the relevant data of the target non-preset application according to the detection strategy; and when the detection result indicates that the target non-preset application conforms to the risk applications included in the detection strategy, alerting the user to the risk application through the user terminal.

[0006] Secondly, embodiments of this specification provide a method for risk alerts. This method includes: acquiring relevant data on non-preset applications collected by various terminal manufacturers from various user terminals, wherein the non-preset applications are applications not downloaded through preset download channels, and the relevant data includes at least application download data; performing a risk application detection operation on the relevant data to identify risky applications among the non-preset applications; determining a detection strategy for the risky applications based on the relevant data corresponding to the risky applications; and sending the detection strategy to the user terminal so that the user terminal uses the detection strategy to alert the user to the risky applications.

[0007] Thirdly, embodiments of this specification provide a risk alert device, comprising: a policy acquisition module, configured to acquire detection policies for non-preset applications downloaded from a cloud server, wherein the non-preset applications are applications not downloaded through a preset download channel; a risk detection module, configured to perform risk application detection operations on relevant data of the target non-preset application according to the detection policy when a user performs related actions targeting the target non-preset application through the user terminal; and a risk alert module, configured to alert the user of the risk application through the user terminal when the detection result indicates that the target non-preset application conforms to the risk application included in the detection policy.

[0008] Fourthly, embodiments of this specification provide a risk alert device, comprising: an application acquisition module, configured to acquire relevant data of non-preset applications collected by various terminal manufacturers from various user terminals, wherein the non-preset applications are applications not downloaded through preset download channels, and the relevant data includes at least application download data; a risk application module, configured to perform risk application detection operations on the relevant data to identify risk applications among the non-preset applications; a strategy determination module, configured to determine a detection strategy for the risk application based on the relevant data corresponding to the risk application; and a strategy delivery module, configured to send the detection strategy to the user terminal so that the user terminal uses the detection strategy to alert the user to the risk application.

[0009] Fifthly, embodiments of this specification provide an electronic device comprising: a processor and a memory arranged to store computer-executable instructions, wherein, when the executable instructions are executed, the processor is capable of: acquiring a detection strategy for non-preset applications downloaded from a cloud server, wherein the non-preset applications are applications not downloaded through a preset download channel; performing a detection operation on the relevant data of the target non-preset application for risky applications according to the detection strategy when a user performs an action related to the target non-preset application through the user terminal; and providing a risky application warning to the user through the user terminal when the detection result indicates that the target non-preset application conforms to the risky applications included in the detection strategy.

[0010] Sixthly, embodiments of this specification provide an electronic device comprising: a processor and a memory arranged to store computer-executable instructions, wherein, when the executable instructions are executed, the processor is enabled to: acquire relevant data of non-preset applications collected by various terminal manufacturers from various user terminals, wherein the non-preset applications are applications not downloaded through preset download channels, and the relevant data includes at least application download data; perform a detection operation on the relevant data for risky applications to identify risky applications among the non-preset applications; determine a detection strategy for the risky applications based on the relevant data corresponding to the risky applications; and send the detection strategy to the user terminal so that the user terminal uses the detection strategy to remind the user of the risky applications.

[0011] Seventhly, embodiments of this specification provide a storage medium for storing a computer program that can be executed by a processor to implement the following process: acquiring a detection strategy for non-preset applications downloaded from a cloud server, wherein the non-preset applications are applications not downloaded through a preset download channel; when a user performs actions related to the target non-preset application through the user terminal, performing a risk application detection operation on the relevant data of the target non-preset application according to the detection strategy; and when the detection result indicates that the target non-preset application conforms to the risk application included in the detection strategy, reminding the user of the risk application through the user terminal.

[0012] Eighthly, embodiments of this specification provide a storage medium for storing a computer program that can be executed by a processor to implement the following process: acquiring relevant data of non-preset applications collected by various terminal manufacturers from various user terminals, wherein the non-preset applications are applications not downloaded through preset download channels, and the relevant data includes at least application download data; performing a detection operation on the relevant data for risky applications to identify risky applications among the non-preset applications; determining a detection strategy for the risky applications based on the relevant data corresponding to the risky applications; and sending the detection strategy to the user terminal so that the user terminal uses the detection strategy to remind the user of the risky applications.

[0013] Ninthly, embodiments of this specification provide a computer program product, including a computer program that, when executed by a processor, implements the following process: acquiring a detection strategy for non-preset applications downloaded from a cloud server, wherein the non-preset applications are applications not downloaded through a preset download channel; when a user performs actions related to a target non-preset application through a user terminal, performing a risk application detection operation on the relevant data of the target non-preset application according to the detection strategy; and when the detection result indicates that the target non-preset application conforms to the risk application included in the detection strategy, reminding the user of the risk application through the user terminal.

[0014] Tenthly, embodiments of this specification provide a computer program product, including a computer program that, when executed by a processor, implements the following process: acquiring relevant data of non-preset applications collected by various terminal manufacturers from various user terminals, wherein the non-preset applications are applications not downloaded through preset download channels, and the relevant data includes at least application download data; performing a detection operation on the relevant data for risky applications to identify risky applications among the non-preset applications; determining a detection strategy for the risky applications based on the relevant data corresponding to the risky applications; and sending the detection strategy to the user terminal so that the user terminal uses the detection strategy to remind the user of the risky applications. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in one or more embodiments of this specification or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in one or more embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a flowchart illustrating a risk warning method provided in an embodiment of this specification; Figure 2 This is a framework diagram of a cloud-edge collaborative risk alert system provided in the embodiments of this specification; Figure 3 This is a schematic diagram illustrating an application scenario of a risk warning method provided in the embodiments of this specification; Figure 4 This is a flowchart illustrating a risk warning method provided in an embodiment of this specification; Figure 5 This is a schematic diagram of the structure of a risk warning device provided in the embodiments of this specification; Figure 6This is a schematic diagram of the structure of a risk warning device provided in the embodiments of this specification; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this specification. Detailed Implementation

[0017] The technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments in this specification. All other embodiments obtained by those skilled in the art based on the embodiments in this specification without creative effort are within the scope of protection of this document.

[0018] The terms "first," "second," etc., used in this specification and claims are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this specification can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0019] The risk warning method, apparatus, and electronic device provided in this specification will be described in detail below with reference to the accompanying drawings and through specific embodiments and application scenarios.

[0020] Figure 1 This illustration shows a risk warning method provided by an embodiment of the present invention. The method can be executed by an electronic device, which may include a terminal device, such as an in-vehicle terminal or a mobile phone terminal. In other words, the method can be executed by software or hardware installed in the aforementioned electronic device. The risk warning method includes the following steps: Step S102: Obtain the detection strategy for non-preset applications downloaded from the cloud server.

[0021] Non-preset applications are those not downloaded through preset download channels. Preset download channels can include: downloading from app stores provided by the terminal device manufacturer or well-known third-party platforms, or downloading using security software that performs security checks on downloaded applications. Since applications in app stores typically undergo rigorous review, and security software performs security checks on downloaded applications, software downloaded through these preset channels usually has higher security. This manual does not specifically limit the preset download channels; they can be determined and updated according to actual circumstances.

[0022] In various online fraud scenarios, to avoid being reviewed by manufacturers or third-party platforms, illegal online industries often guide users to download and install applications developed by these illegal industries on the user's device through unauthorized download channels. These applications downloaded through unauthorized channels are called unauthorized applications. Currently, unauthorized download channels include downloading via methods such as using identification codes and links.

[0023] To provide security for user terminals, cloud servers periodically crawl installation packages of non-preset applications from the internet, analyze and identify these applications on the cloud server, and finally send the identification results (including a list of malicious applications) to the user terminal through the terminal manufacturer, enabling the user terminal to identify malicious applications identified in the results. However, because malicious applications have a very short lifespan (sometimes only two or three days), by the time the cloud server identifies the malicious application, it may already be inactive. Therefore, this type of solution is usually lagging behind.

[0024] To achieve timely alerts for malicious applications on user terminals, in one example, a lightweight detection policy targeting non-preset applications can be formulated on a cloud server. This policy is easy to execute on user terminals and can be implemented directly. The cloud server provides the detection policy to the user terminal through the terminal manufacturer or an end-to-cloud collaborative link (a link built between the application terminal and the cloud server). This decentralizes the malicious application detection process to the user terminal, improving the real-time nature of risk alerts. Furthermore, the proportion of malicious applications in installation packages crawled from the internet is low and unstable, while the proportion of malicious applications from non-preset channels provided by the user terminal is higher, which improves the accuracy of the detection policy. To prevent the detection policy from being tampered with by malicious applications, in one example, the detection policy can be set in a Trusted Execution Environment (TEE).

[0025] Specifically, a detection strategy can be composed of multiple different conditions linked by predefined logical operations. Each condition in a detection strategy can contain three elements: a feature, a comparison value, and a logical operator. For example, in the detection strategy (feture1>1 or feature1<0) and feature2!=-1 and feature3>0, it contains four conditions (i.e., feature1>1, feature1<0, feature2!=-1, and feature3>0) and three logical operations (i.e., or, and, and). Each condition contains features (i.e., feature1, feature2, and feature3), comparison values ​​(1, 0, -1, and 0), and logical operators (>, <, !=, and >). This specification does not specifically limit the content of the features; they can be determined according to the actual situation. To improve the detection efficiency of risk applications, in one example, the cloud server can convert each detection strategy into a detection model and send it to the user terminal. Furthermore, this detection model can also be constructed based on the detection strategy and / or risk features (static and dynamic features). This manual does not specify the structure and training process of the detection model; these can be determined based on the actual situation.

[0026] Step S104: When a user performs actions related to a target non-preset application through a user terminal, the relevant data of the target non-preset application is subjected to detection operations for risky applications according to the detection strategy.

[0027] The target non-preset application can be any non-preset application that is about to run or is currently running on the user's terminal. The related behavior can be actions performed by the user corresponding to the target non-preset application, such as downloading or using it (data entry, browsing, querying, etc.). The static data or dynamic data generated by the target non-preset application during the execution of these actions constitutes the related data. Static data is the data used when downloading the application, while dynamic data is the data generated when using the application.

[0028] Since the relevant data of the target non-preset application corresponding to different related behaviors are different, the cloud server can set different detection strategies based on the relevant data generated by different related behaviors. In turn, the user terminal can execute different detection strategies on the relevant data corresponding to different related behaviors based on the detection strategies.

[0029] Specifically, before a target non-preset application is installed on a user's terminal, a link or QR code is required to redirect to the corresponding download address and verify the application signature. Therefore, before installation, the relevant data can be static data such as links, QR codes, and signatures. Detection strategies corresponding to this static data can then be used to detect the target non-preset application as a risky application. After the target non-preset application is installed on the user's terminal, the relevant data can be dynamic data such as file directory structures generated with version updates and the accumulation of user information. Detection strategies corresponding to this dynamic data can then be used to detect the target non-preset application as a risky application.

[0030] Step S106: If the detection result indicates that the target application is not a preset application and meets the risk application included in the detection strategy, remind the user of the risk application through the user terminal.

[0031] The detection result refers to the outcome of the aforementioned detection operation, which typically includes two types of results: First, the target non-preset application meets the risk criteria included in the detection strategy, meaning the target non-preset application is a risky application; second, the target non-preset application does not meet the risk criteria included in the detection strategy, meaning the target non-preset application is not a risky application. For the first result, the user can be alerted via their terminal to stop the operation, delete the application, and pay attention to financial account security. For the second result, dynamic data can continue to be monitored to ensure the user's financial security.

[0032] Figure 2 A framework diagram of an edge-cloud collaborative risk alert system is provided. For example... Figure 2 As shown, the risk alert system includes a cloud server and an application terminal. The cloud server distributes the detection policy to the application terminal so that the user terminal can detect risky applications through the detection policy.

[0033] In the embodiments described in this specification, a detection strategy for non-preset applications, determined by the cloud server, is set on the user terminal. When the user performs relevant actions, the detection strategy is used to detect relevant data, and the user is alerted if the target non-preset application is detected as a risky application. This process proposes a novel end-to-cloud collaborative risk alert framework for non-preset applications. By delegating the detection strategy from the cloud server to the user terminal, it leverages the powerful computing capabilities of the cloud server to obtain a highly reliable detection strategy while utilizing the high real-time performance of the user terminal to achieve rapid response to risky applications. This effectively improves the real-time nature and adversarial nature of risk alerts, thereby enhancing the robustness of the risk alert process.

[0034] Figure 3 An application scenario diagram of a risk alert method is provided, such as... Figure 3As shown, the cloud server provides the user terminal with detection strategies for non-preset applications through the terminal manufacturer or the end-to-cloud collaborative link. The user terminal uses the risk warning method in this manual to remind the user of risky applications.

[0035] The detection strategy provided by the cloud server to the user terminal can include features of various risky applications. By comparing these features with features extracted from relevant data, risk detection operations can be performed on target applications that are not pre-defined. In one implementation, the relevant behavior includes application download behavior. Step S104 can be executed as follows: Steps A1-A2: Step A1: When a user performs an application download action through a user terminal, extract the features of the download data corresponding to the application download action to obtain the first feature; Step A2: Use the static features of the downloaded data corresponding to the risky application in the detection strategy to perform a detection operation on the first feature.

[0036] Downloaded data refers to the data required to download the application, which may include link data, signature data, QR code data, etc. Static features are the characteristics of the downloaded data corresponding to risky applications, with the first feature being the characteristics of the downloaded data corresponding to applications whose targets are not preset applications. For example... Figure 2 As shown, the cloud server can set up a feature library of static and dynamic features and send it to the user terminal along with the detection strategy for risk detection.

[0037] Specifically, after obtaining the detection strategy, downloaded data such as link data, signature data, and QR code data can be converted into vector data and used as the first feature. This specification does not specify a particular method for obtaining the first feature; it can be determined based on the actual situation.

[0038] After determining the first feature, it can be matched with its corresponding static features in the detection strategy to perform a detection operation on the first feature. A successful match indicates that the target is neither a pre-defined application nor a risky application included in the detection strategy. The static features corresponding to the first feature can be determined based on the data type. For example, if the first feature is a feature corresponding to the link data of a target non-pre-defined application, then the static features corresponding to the first feature are the features of the link data of the risky application.

[0039] Whether the primary feature and the static feature match can be determined using a similarity measurement method, such as the distance or angle between the primary feature and the static feature. When the similarity value is greater than a threshold, the primary feature and the static feature being compared can be considered to match. Similarity measurement methods can include Euclidean distance, cosine similarity, Pearson correlation coefficient, etc. This specification does not restrict which similarity measurement method is used.

[0040] While collecting information on risky applications to build detection strategies, the cloud server can also collect information on non-risky applications. In one implementation, the detection strategy includes a whitelist for excluding non-risky applications. Step A2 can be executed as follows: Steps B1-B2: Step B1: Based on the static characteristics of the download data corresponding to non-risk applications in the whitelist, perform an early detection operation on the first feature; Step B2: If the detection result of the pre-detection operation indicates that the target is not a preset application and does not conform to the non-risk application, the static features of the downloaded data corresponding to the risk application in the detection strategy are used to perform a detection operation on the first feature.

[0041] Among them, non-risk applications are those determined by the cloud server to be risk-free. The whitelist can be a collection of non-risk applications and legitimate digital signature certificates gathered by the cloud server. The whitelist may include download link whitelists, digital certificate whitelists, etc., and can be set in the detection strategy. Specifically, the cloud server can collect terminal applications and digital signature certificates published on the websites of various certified internet companies, and construct a download link whitelist (i.e., ...) based on the download links of these terminal applications. Figure 2 The URL whitelist library in the database), and the digital certificate whitelist (i.e., the whitelist of signed certificates) is built based on this data. Figure 2 (CA whitelist database).

[0042] In one example, the cloud server can extract the static features of download data and digital signature certificates of each non-risk application in the whitelist, and set the feature library composed of these static features together with the whitelist in the detection strategy. After determining the first feature, the static features in the whitelist can be used to perform a preliminary detection operation on the first feature. This preliminary detection operation is performed before the detection operation on the first feature.

[0043] The method for early detection is similar to the aforementioned method of detecting the first feature using the static features of risky applications, and will not be described in detail here. Furthermore, if the detection result corresponding to the early detection operation indicates that the target non-preset application does not conform to the non-risk application in the whitelist, the detection strategy can continue to be used to detect the first feature; if the early detection result indicates that the target non-preset application conforms to the non-risk application in the whitelist, then the tracking and detection of the target non-preset application can be stopped.

[0044] The above process, by performing early detection of the first feature through a whitelist, can save computing resources on the user terminal when the target application is not a preset application and meets the criteria of being a non-risk application in the whitelist.

[0045] In the embodiments of this specification, the detection operation of the target non-preset application during the application download stage is realized by using the first feature of the target non-preset application and the static feature of the risky application, which helps to improve the security of the user terminal when downloading the target non-preset application.

[0046] In one implementation, the relevant behaviors include application usage behaviors. Step S104 can be executed as follows: steps C1-C2: Step C1: When a user performs application usage behavior through a user terminal, extract the features of the usage data corresponding to the application usage behavior to obtain the second feature; Step C2: Use the dynamic features of the usage data corresponding to the risk application in the detection strategy to perform a detection operation on the second feature.

[0047] The usage data refers to the data generated by the application, which may include interface keyword data, file directory structure data, recommended product time data, Android installation package data (APK data), etc. Dynamic features are the characteristics of the usage data corresponding to the risky application, and the second feature is the characteristics of the usage data generated by the application other than the preset application.

[0048] Specifically, after obtaining the detection strategy, usage data such as interface keyword data, file directory structure data, and recommended product time data can be converted into vector data and used as the second feature. This specification does not specify a particular method for obtaining the second feature; it can be determined based on the actual situation.

[0049] After determining the second feature, it can be matched with its corresponding dynamic features in the detection strategy to perform detection. A successful match indicates that the target is neither a pre-defined application nor a risky application included in the detection strategy. The dynamic features corresponding to the second feature can be determined based on data type. For example, if the second feature corresponds to the interface keyword data of a target non-pre-defined application, then the dynamic features corresponding to the interface keyword data of the risky application are the same.

[0050] Whether the second feature and the dynamic feature match can be determined using similarity measurement methods, such as the distance or angle between the second feature and the dynamic feature. When the similarity value is greater than the threshold, it can be determined that the second feature and the dynamic feature being compared match.

[0051] like Figure 2As shown, the user terminal can be equipped with a feature extraction module and a feature analysis module. The former is used to extract the first feature and the second feature, while the latter is used to perform detection operations on the first feature using static features in the detection strategy and on the second feature using dynamic features in the detection strategy. Alternatively, the aforementioned detection model can be used to directly perform detection operations on the first and second features.

[0052] In the embodiments of this specification, the detection operation of the target non-preset application during the application usage stage is realized by using the second feature of the target non-preset application and the dynamic feature of the risky application, which helps to improve the security of the user terminal when using the target non-preset application.

[0053] After risk detection is performed on the user terminal using the detection strategy, non-preset applications can be collected on the user terminal and sent to the cloud server to update the detection strategy. In one implementation, the risk alert method also includes: The downloaded data of the target non-preset application is sent to the cloud server so that the cloud server can perform a risk detection operation on the target non-preset application.

[0054] Specifically, in addition to performing risk detection on non-preset applications on the user terminal, the non-preset applications can also be sent to the cloud server to achieve accurate detection of the non-preset applications, and the existing detection strategy can be updated based on the detection results.

[0055] To reduce the computational load on cloud servers and improve the efficiency of detection strategy formulation, the first and / or second characteristics of the target non-preset application can be sent to the cloud server along with the downloaded data of the target non-preset application. Specifically, relevant data of the collaborative detection application can be sent to the cloud server through the end-to-cloud collaborative link.

[0056] In one example, a whitelist can be used to filter target non-preset applications. Target non-preset applications that do not meet the criteria for being non-risk applications in the whitelist can then be sent to the cloud server. This reduces the amount of data transmitted between the user terminal and the cloud server while improving the efficiency of updating the cloud server's detection strategy.

[0057] In the embodiments of this specification, the user terminal sends the target non-preset application to the cloud server to utilize the powerful computing capabilities of the cloud server to perform further risk detection on the target non-preset application. Furthermore, the detection strategy can be dynamically updated based on the detection results, thereby improving the countermeasure capability of the risk warning method and enhancing the detection effect of the risky application on the user terminal.

[0058] Figure 4This invention illustrates a risk alert method provided by an embodiment of the present invention. This method can be executed by a cloud server and includes the following steps: Step S402: Obtain relevant data of non-preset applications collected by each terminal manufacturer from each user terminal; Step S404: Perform risk application detection operations on the relevant data to identify risk applications that are not in the preset applications; Step S406: Determine the detection strategy for risky applications based on the relevant data corresponding to the risky applications; Step S408: Send the detection policy to the user terminal so that the user terminal can use the detection policy to remind the user of risky applications.

[0059] Non-preset applications are those not downloaded through pre-defined download channels. As mentioned earlier, pre-defined download channels can be software downloaded from app stores and security software. The acquisition method for non-preset applications can be that the terminal manufacturer uploads relevant data of non-preset applications collected from the user terminal to the cloud server at an agreed-upon time frequency (e.g., once a day). The terminal manufacturer is the manufacturer of the terminal device that agrees with the cloud server on providing relevant data for non-preset applications. It should be understood that the various user terminals in step S402 can be different. Compared to the workload required to crawl non-preset applications from the entire network, the workload of obtaining non-preset applications through the terminal manufacturer is greatly reduced. Furthermore, since the cloud server and the user terminal do not directly interact with each other, user privacy can be protected.

[0060] Related data refers to data used or generated when operating non-preset applications. Related data includes at least application download data. In the embodiments of this specification, related data for non-preset applications may be download data of the non-preset application, such as download QR code data, download link data, etc. Figure 2 As shown, in addition to the above, the relevant data may also include features of non-preset applications extracted by the user terminal, such as features of static data and features of dynamic data. Static data refers to the data used to download non-preset applications, while dynamic data refers to the data generated by using non-preset applications.

[0061] After acquiring relevant data from multiple non-preset applications, risk application detection can be performed on these applications using this data. Specifically, a risk application detection model can be built on a cloud server, and this trained model can be used to detect risk applications from the collected non-preset applications. This risk application detection model can determine whether a non-preset application is a risk application based on both static and dynamic data. This specification does not specify the exact structure and training process of the risk application detection model; these can be determined according to the actual situation.

[0062] Before performing risk detection on non-preset applications, a whitelist set up on the cloud server can be used to exclude non-risk applications. Specifically, the whitelist can be a collection of non-risk applications and legitimate digital signature certificates gathered by the cloud server; that is, the whitelist can include download link whitelists, digital certificate whitelists, etc., and can be set in the detection strategy. Specifically, the cloud server can use the link whitelist and the data certificate whitelist sequentially to filter non-risk applications. After these two layers of filtering, the number of non-preset applications to be detected will be reduced. This can improve the hit rate of risky applications while also improving the efficiency of building the cloud server's detection strategy.

[0063] Cloud servers can determine detection strategies based on relevant data from risky applications. Specifically, they can determine strategies based on the characteristics of the static and dynamic data of risky applications. For example, if the signature data (static data) of risky applications differs from that of non-risky applications, a detection strategy can be determined based on the characteristics of the signature data of the risky application; similarly, if the file directory structure data (dynamic data) of risky applications differs from that of non-risky applications, a detection strategy can be determined based on the characteristics of the file directory structure data of the risky application.

[0064] Furthermore, the detection strategy can be sent to the terminal manufacturer, enabling the manufacturer to distribute the detection strategy to the user terminal. The receiving user terminal can then use this strategy to detect risky applications that are not pre-defined. Additionally, the cloud server can also use an end-to-end collaborative link to distribute the detection strategy to the user terminal.

[0065] In the embodiments described in this specification, a detection strategy is formulated on the cloud server based on relevant data from non-preset applications provided by the user terminal, and the detection strategy is then distributed to the user terminal. This process proposes a novel end-to-cloud collaborative risk alert framework for non-preset applications. By delegating the detection strategy from the cloud server to the user terminal, it leverages the powerful computing capabilities of the cloud server to obtain a highly reliable detection strategy while utilizing the high real-time performance of the user terminal to achieve rapid response to risky applications. This effectively improves the real-time nature and adversarial capabilities of risk alerts, thereby enhancing the robustness of the risk alert process.

[0066] In one implementation, the relevant data includes download data and usage data. Step S406 can be executed as follows: steps D1-D3: Step D1: Extract the static features of the risky application from the download data corresponding to the risky application. The download data is the data required to download the application. Step D2: Download the risky application using the download data corresponding to the risky application, and extract the dynamic characteristics of the risky application from the usage data corresponding to the risky application. The usage data is the data generated by the application. Step D3: Determine the detection strategy for the risk application based on its static and / or dynamic characteristics.

[0067] Typically, to reduce the amount of data that terminal manufacturers transmit to cloud servers, they can only send download data for non-pre-installed applications to the cloud server for analysis. For example, terminal manufacturers can only send download link data for non-pre-installed applications to the cloud server. After obtaining download data such as download link data for non-pre-installed applications, the cloud server can also obtain download data including signature data based on the download links. Furthermore, the cloud server can extract static features of risky applications from the download data (such as download link data, signature data, etc.) corresponding to risky applications.

[0068] As mentioned earlier, the data from risky applications can include download data from when the application is downloaded and usage data from when it is used. Therefore, dynamic features can also be extracted from the usage data corresponding to the risky application. Specifically, the cloud server can use download link data, etc., to download non-preset applications, and by using these non-preset applications, obtain dynamic data. Furthermore, the dynamic features of the risky application can be extracted from the dynamic data (such as file directory structures).

[0069] Furthermore, detection strategies can be determined based on the static and / or dynamic characteristics of risky applications. Specifically, detection strategies can be determined when a user terminal downloads a non-preset application based on the static characteristics of the risky application; and detection strategies can be determined when a user terminal uses a target non-preset application based on the dynamic characteristics of the risky application.

[0070] In the embodiments described in this specification, static features of risky applications are extracted from download data corresponding to risky applications, and dynamic features of risky applications are extracted from usage data corresponding to risky applications. A detection strategy is then determined based on the dynamic and / or static features. This process establishes a two-stage detection strategy for non-risky applications, covering both download and usage phases, providing comprehensive protection for users when they perform operations related to non-risky applications on their terminals.

[0071] In various online fraud scenarios, illicit online industries often use the same development framework or similar signature methods to develop risky applications in order to save costs and improve development efficiency. In one implementation, step D1 can be executed as follows: steps F1-F2: Step F1: Based on the downloaded data of at least one preset category, perform a clustering operation on the risky applications to obtain at least one first cluster. Step F2: Extract the static features of risky applications from the download data of risky applications corresponding to each first cluster. Step D1 can be executed as follows: steps F3-F4: Step F3: Based on usage data of at least one preset category, perform clustering operations on risky applications to obtain at least one second cluster. Step F4: Extract the static features of risky applications from the download data of risky applications corresponding to each second cluster.

[0072] Downloaded data and usage data can be categorized based on their data types. Specifically, downloaded data can be categorized into types such as signature data and download link data, while usage data can be categorized into types such as keyword data and frame data.

[0073] In one example, risky applications can be clustered based on download data of at least one preset category, with the first cluster being the cluster obtained by this clustering operation. Furthermore, static features of the risky applications can be extracted from the download data corresponding to each of the first clusters. Specifically, static features of the risky applications can be extracted from download data of preset categories and / or download data of other categories within the first clusters.

[0074] In the above steps, since the risky applications in the same first cluster are quite similar, the static features extracted from the download data of multiple risky applications in the first cluster are more representative than those extracted directly from the download data of risky applications. Therefore, the detection strategy formulated using these static features can have better detection capabilities.

[0075] Similarly, risky applications can be clustered based on usage data of at least one preset category, and the second cluster is the cluster obtained by this clustering operation. Furthermore, dynamic characteristics of risky applications can be extracted from the download data corresponding to each second cluster. Specifically, dynamic characteristics of risky applications can be extracted from usage data of preset categories and / or usage data other than preset categories within the second cluster.

[0076] In the above steps, since the risk applications in the same second cluster are quite similar, the dynamic features extracted from the usage data of multiple risk applications in the second cluster are more representative than those extracted directly from the usage data of risk applications. Therefore, the detection strategy formulated using these dynamic features has better detection capabilities.

[0077] like Figure 2As shown, after receiving high-risk APK download traffic (i.e., acquiring non-preset applications collected by terminal manufacturers from user terminals at a preset frequency), the cloud server obtains and analyzes static and dynamic features, and can construct a feature library based on these features. Figure 2 In the feature library, family features are the APK characteristics of the risky application, package body features are the characteristics of the folder after the risky application is decompressed, framework features are the characteristics of the development framework of the risky application, and signature features are the characteristics of the signature of the risky application. These four features can be obtained using clustering operations. It should be noted that the risk alert method provided in the embodiments of this specification can be executed by a risk alert device or a control module within that device for executing the risk alert method. This specification uses the example of a risk alert device executing a risk alert method to illustrate the risk alert device provided in the embodiments of this specification.

[0078] Figure 5 This is a schematic diagram of the structure of a risk warning device according to an embodiment of the present invention. Figure 5 As shown, the risk warning device 500 includes: The policy acquisition module 510 is used to acquire detection policies for non-preset applications downloaded from the cloud server. Non-preset applications are those that were not downloaded through the preset download channels. The risk detection module 520 is used to perform risk detection operations on the relevant data of the target non-preset application according to the detection strategy when the user performs relevant actions against the target non-preset application through the user terminal. The risk alert module 530 is used to alert the user to the risk application through the user terminal when the detection result indicates that the target application is not a preset application and meets the risk application included in the detection strategy.

[0079] In one embodiment, the relevant behavior includes application download behavior, and the risk detection module 520 includes: The first extraction unit is used to extract the features of the download data corresponding to the application download behavior when the user performs the application download behavior through the user terminal, and obtain the first feature, wherein the download data is the data required to download the application. The first detection unit is used to perform a detection operation on the first feature by using the static features of the downloaded data corresponding to the risky application in the detection strategy.

[0080] In one embodiment, the relevant behaviors include application usage behaviors, and the risk detection module 520 includes: The second extraction unit is used to extract the features of the usage data corresponding to the application usage behavior when the user performs application usage behavior through the user terminal, and obtain the second feature. The usage data is the data generated by using the application. The second detection unit is used to perform detection operations on the second feature by using the dynamic features of the usage data corresponding to the risk application in the detection strategy.

[0081] In one embodiment, the detection strategy includes a whitelist for excluding non-risk applications, and a first detection unit is used for: Based on the static characteristics of the download data corresponding to non-risk applications in the whitelist, an early detection operation is performed on the first characteristic; If the detection results of the pre-detection operation indicate that the target is not a preset application and does not conform to a non-risk application, the static features of the downloaded data corresponding to the risk application in the detection strategy are used to perform a detection operation on the first feature.

[0082] In one embodiment, the risk alert device 500 further includes: The upload module is used to send the downloaded data of the target non-preset application to the cloud server, so that the cloud server can perform a risk detection operation on the target non-preset application.

[0083] It should be noted that the embodiments of the risk warning device and the embodiments of the risk warning method in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding risk warning method described above, and the repeated parts will not be described again.

[0084] The various modules in the aforementioned risk warning device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the terminal device or the processor on the server, or stored in the memory of the terminal device or the memory on the server, so that the processor can call and execute the corresponding operations of each module.

[0085] Figure 6 This is a schematic diagram of the structure of a risk warning device according to an embodiment of the present invention. Figure 6 As shown, the risk alert device 600 includes: The application acquisition module 610 is used to acquire relevant data of non-preset applications collected by various terminal manufacturers from various user terminals. Non-preset applications are applications that have not been downloaded through preset download channels. The relevant data includes at least the application download data. The risk application module 620 is used to perform risk application detection operations on relevant data to identify risk applications that are not preset applications. The strategy determination module 630 is used to determine the detection strategy for risky applications based on the relevant data corresponding to the risky applications. The policy delivery module 640 is used to send the detection policy to the user terminal so that the user terminal can remind the user of risky applications when using the detection policy.

[0086] In one embodiment, the relevant data includes download data and usage data, and the policy determination module 630 includes: The static unit is used to extract the static features of the risky application from the download data corresponding to the risky application. The download data is the data required to download the application. The dynamic unit is used to download the risky application using the download data corresponding to the risky application, and extract the dynamic characteristics of the risky application from the usage data corresponding to the risky application. The usage data is the data generated by the application. The strategy unit is used to determine the detection strategy for a risk application based on its static and / or dynamic characteristics.

[0087] In one embodiment, the static unit is used for: Based on download data of at least one preset category, perform clustering operations on risky applications to obtain at least one first cluster. Extract static features of risky applications from the download data of risky applications corresponding to each first cluster; From the usage data corresponding to risky applications, extract the dynamic characteristics of the risky applications, including: Based on usage data of at least one preset category, cluster the risky applications to obtain at least one second cluster; Static features of risky applications are extracted from the download data of risky applications corresponding to each second cluster.

[0088] It should be noted that the embodiments of the risk warning device and the embodiments of the risk warning method in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding risk warning method described above, and the repeated parts will not be described again.

[0089] The various modules in the aforementioned risk warning device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the terminal device or the processor on the server, or stored in the memory of the terminal device or the memory on the server, so that the processor can call and execute the corresponding operations of each module.

[0090] Furthermore, corresponding to the risk warning method described above, based on the same technical concept, one or more embodiments of this specification also provide an electronic device for executing the aforementioned risk warning method. Figure 7 This is a schematic diagram of the structure of an electronic device provided for one or more embodiments of this specification.

[0091] Based on the same idea, one or more embodiments of this specification also provide an electronic device, such as... Figure 7 As shown. Electronic devices can vary considerably due to differences in configuration or performance, and may include one or more processors 701 and memory 702. Memory 702 may store one or more application programs or data. Memory 702 may be temporary or persistent storage. The application programs stored in memory 702 may include one or more modules (not shown), each module may include a series of computer-executable instructions for the electronic device. Furthermore, processor 701 may be configured to communicate with memory 702 and execute the series of computer-executable instructions in memory 702 on the electronic device. The electronic device may also include one or more power supplies 703, one or more wired or wireless network interfaces 704, one or more input / output interfaces 705, and one or more keyboards 706.

[0092] In one specific embodiment, the electronic device includes a memory and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs may include one or more modules, and each module may include a series of computer-executable instructions for use in the electronic device, and is configured to be executed by one or more processors. The one or more programs include computer-executable instructions for performing the following: Obtain the detection strategy for non-preset applications downloaded from the cloud server. Non-preset applications are those that were not downloaded through the preset download channels. When a user performs actions targeting a non-preset application through a user terminal, the relevant data of the non-preset application is subjected to detection operations targeting risky applications according to the detection strategy. If the detection results indicate that the target application is not a preset application and meets the risk application included in the detection strategy, the user will be alerted about the risk application through the user terminal.

[0093] It should be noted that the embodiments of electronic devices in this specification and the embodiments of risk warning methods in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding risk warning method mentioned above, and the repeated parts will not be described again.

[0094] In one specific embodiment, the electronic device includes a memory and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs may include one or more modules, and each module may include a series of computer-executable instructions for use in the electronic device, and is configured to be executed by one or more processors. The one or more programs include computer-executable instructions for performing the following: Acquire relevant data on non-preset applications collected by various terminal manufacturers from various user terminals. Non-preset applications are those that were not downloaded through the preset download channels. The relevant data includes at least the application download data. Perform risk detection operations on the relevant data to identify risky applications that are not pre-defined applications; Based on the relevant data corresponding to the risky applications, determine the detection strategy for the risky applications; The detection strategy is sent to the user terminal so that the user terminal can use the detection strategy to alert the user to risky applications.

[0095] It should be noted that the embodiments of electronic devices in this specification and the embodiments of risk warning methods in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding risk warning method mentioned above, and the repeated parts will not be described again.

[0096] Furthermore, corresponding to the risk warning method described above, based on the same technical concept, one or more embodiments of this specification also provide a storage medium for storing computer-executable instructions. In a specific embodiment, the storage medium can be a USB flash drive, optical disc, hard disk, etc. When the computer-executable instructions stored in the storage medium are executed by a processor, they can achieve the following process: Obtain the detection strategy for non-preset applications downloaded from the cloud server. Non-preset applications are those that were not downloaded through the preset download channels. When a user performs actions targeting a non-preset application through a user terminal, the relevant data of the non-preset application is subjected to detection operations targeting risky applications according to the detection strategy. If the detection results indicate that the target application is not a preset application and meets the risk application included in the detection strategy, the user will be alerted about the risk application through the user terminal.

[0097] It should be noted that the embodiments of the storage medium in this specification and the methods of risk warning in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding risk warning method mentioned above, and the repeated parts will not be described again.

[0098] Furthermore, corresponding to the risk warning method described above, based on the same technical concept, one or more embodiments of this specification also provide a storage medium for storing computer-executable instructions. In a specific embodiment, the storage medium can be a USB flash drive, optical disc, hard disk, etc. When the computer-executable instructions stored in the storage medium are executed by a processor, they can achieve the following process: Acquire relevant data on non-preset applications collected by various terminal manufacturers from various user terminals. Non-preset applications are those that were not downloaded through the preset download channels. The relevant data includes at least the application download data. Perform risk detection operations on the relevant data to identify risky applications that are not pre-defined applications; Based on the relevant data corresponding to the risky applications, determine the detection strategy for the risky applications; The detection strategy is sent to the user terminal so that the user terminal can use the detection strategy to alert the user to risky applications.

[0099] It should be noted that the embodiments of the storage medium in this specification and the methods of risk warning in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding risk warning method mentioned above, and the repeated parts will not be described again.

[0100] Furthermore, corresponding to the risk warning method described above, based on the same technical concept, one or more embodiments of this specification also provide a computer program product, which includes a computer program that, when executed by a processor, can implement the following process: Obtain the detection strategy for non-preset applications downloaded from the cloud server. Non-preset applications are those that were not downloaded through the preset download channels. When a user performs actions targeting a non-preset application through a user terminal, the relevant data of the non-preset application is subjected to detection operations targeting risky applications according to the detection strategy. If the detection results indicate that the target application is not a preset application and meets the risk application included in the detection strategy, the user will be alerted about the risk application through the user terminal.

[0101] It should be noted that the embodiments of the computer program product in this specification and the embodiments of the risk warning method in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding risk warning method mentioned above, and the repeated parts will not be described again.

[0102] Furthermore, corresponding to the risk warning method described above, based on the same technical concept, one or more embodiments of this specification also provide a computer program product, which includes a computer program that, when executed by a processor, can implement the following process: Acquire relevant data on non-preset applications collected by various terminal manufacturers from various user terminals. Non-preset applications are those that were not downloaded through the preset download channels. The relevant data includes at least the application download data. Perform risk detection operations on the relevant data to identify risky applications that are not pre-defined applications; Based on the relevant data corresponding to the risky applications, determine the detection strategy for the risky applications; The detection strategy is sent to the user terminal so that the user terminal can use the detection strategy to alert the user to risky applications.

[0103] It should be noted that the embodiments of the computer program product in this specification and the embodiments of the risk warning method in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding risk warning method mentioned above, and the repeated parts will not be described again.

[0104] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0105] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0106] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0107] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0108] For ease of description, the above apparatus is described by dividing it into various functional units. Of course, when implementing the embodiments of this specification, the functions of each unit can be implemented in one or more software and / or hardware.

[0109] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this specification may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0110] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0111] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0112] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0113] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0114] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0115] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0116] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0117] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0118] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0119] The above description is merely an embodiment of this document and is not intended to limit the scope of this document. Various modifications and variations can be made to this document by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this document should be included within the scope of the claims of this document.

Claims

1. A risk alert method for use on a user terminal, comprising: The system obtains detection strategies for non-preset applications downloaded from a cloud server. The non-preset applications are those not downloaded through a pre-defined download channel. The cloud server sets different detection strategies based on relevant data generated by different related behaviors. The detection strategy is generated by the cloud server performing clustering operations on the risky applications based on the relevant data corresponding to the risky applications, extracting static and / or dynamic features of the risky applications from the relevant data of the risky applications corresponding to the clusters, and generating the strategy based on the static and / or dynamic features. When a user performs actions related to a target non-preset application through the user terminal, the relevant data of the target non-preset application is subjected to risk application detection operations according to the detection strategy. The relevant actions include application download behavior and application usage behavior. If the detection result indicates that the target non-preset application conforms to the risky application included in the detection strategy, the user is reminded of the risky application through the user terminal, and the target non-preset application is sent to the cloud server so that the cloud server can detect the target non-preset application and update the detection strategy based on the detection result.

2. The method according to claim 1, wherein the related behavior includes application download behavior, and the step of performing a risk application detection operation on the related data of the target non-preset application according to the detection strategy when the user performs related behavior targeting a target non-preset application through the user terminal includes: When the user performs the application download behavior through the user terminal, the features of the download data corresponding to the application download behavior are extracted to obtain the first feature, wherein the download data is the data required to download the application. The first feature is detected using the static features of the downloaded data corresponding to the risky application in the detection strategy.

3. The method according to claim 2, wherein the relevant behavior includes application usage behavior, and the step of performing a risk application detection operation on the relevant data of the target non-preset application according to the detection strategy when the user performs relevant behavior targeting a target non-preset application through the user terminal includes: When the user performs the application usage behavior through the user terminal, the features of the usage data corresponding to the application usage behavior are extracted to obtain the second feature, wherein the usage data is the data generated by using the application. The second feature is detected using the dynamic characteristics of the usage data corresponding to the risk application in the detection strategy.

4. The method according to claim 2, wherein the detection strategy includes a whitelist for excluding non-risk applications, and the step of using static features of the download data corresponding to risky applications in the detection strategy to perform a detection operation on the first feature includes: Based on the static characteristics of the download data corresponding to non-risk applications in the whitelist, the first feature is subjected to early detection. If the detection result of the pre-detection operation indicates that the target non-preset application does not conform to the non-risk application, the static features of the download data corresponding to the risk application in the detection strategy are used to perform a detection operation on the first feature.

5. The method according to claim 2, further comprising: The download data of the target non-preset application is sent to the cloud server so that the cloud server can perform a risky application detection operation on the target non-preset application.

6. A method for risk alerting, used on a cloud server, comprising: Acquire relevant data of non-preset applications collected by various terminal manufacturers from various user terminals. The non-preset applications are those that were not downloaded through the preset download channels. The relevant data includes at least the application download data. Perform risk detection operations on the relevant data to identify risky applications among the non-preset applications; Based on the relevant data corresponding to the risky applications, clustering operations are performed on the risky applications. Static and / or dynamic features of the risky applications are extracted from the relevant data of the risky applications corresponding to the clusters. Detection strategies for the risky applications are determined based on the static and / or dynamic features. The cloud server sets different detection strategies for relevant data generated based on different related behaviors, including application download behavior and application usage behavior. The detection strategy is sent to the user terminal so that the user terminal can use the detection strategy to remind the user of risky applications. The system receives a target non-preset application sent by the user terminal, detects the target non-preset application, and updates the detection strategy based on the detection results.

7. The method according to claim 6, wherein the relevant data includes download data and usage data, the download data is the data required to download the application, the usage data is the data generated by using the application, and the step of performing a clustering operation on the risky application based on the relevant data corresponding to the risky application, extracting static features and / or dynamic features of the risky application from the relevant data of the risky application corresponding to the cluster, and determining the detection strategy of the risky application based on the static features and / or dynamic features, includes: Based on download data of at least one preset type, the risky applications are clustered to obtain at least one first cluster. Extract the static features of the risky applications from the download data of the risky applications corresponding to each of the first clusters; Based on usage data of at least one preset category, clustering operations are performed on the risky applications to obtain at least one second cluster; Extract the dynamic features of the risky applications from the download data of the risky applications corresponding to each of the second clusters; The detection strategy for the risk application is determined based on its static and / or dynamic characteristics.

8. A risk alert device, comprising: The strategy acquisition module is used to acquire detection strategies for non-preset applications downloaded from the cloud server. The non-preset applications are those not downloaded through a preset download channel. The cloud server sets different detection strategies based on relevant data generated by different related behaviors. The detection strategy is generated by the cloud server performing clustering operations on the risky applications according to the relevant data corresponding to the risky applications, extracting static and / or dynamic features of the risky applications from the relevant data of the risky applications corresponding to the clusters, and generating the strategy based on the static and / or dynamic features. The risk detection module is used to perform risk detection operations on the relevant data of the target non-preset application according to the detection strategy when the user performs relevant behaviors targeting the target non-preset application through the user terminal. The relevant behaviors include application download behavior and application usage behavior. The risk alert module is used to alert the user to the risk application through the user terminal when the detection result indicates that the target non-preset application meets the risk application included in the detection strategy, and to send the target non-preset application to the cloud server so that the cloud server can detect the target non-preset application and update the detection strategy based on the detection result.

9. A risk warning device, comprising: The application acquisition module is used to acquire relevant data of non-preset applications collected by various terminal manufacturers from various user terminals. The non-preset applications are applications that have not been downloaded through preset download channels. The relevant data includes at least the application download data. The risk application module is used to perform risk application detection operations on the relevant data to identify risk applications that are not preset applications. The strategy determination module is used to perform clustering operations on the risky applications based on the relevant data corresponding to the risky applications, extract static and / or dynamic features of the risky applications from the relevant data of the risky applications corresponding to the clusters, and determine the detection strategy of the risky applications based on the static and / or dynamic features; the cloud server sets different detection strategies for relevant data generated based on different relevant behaviors, including application download behavior and application usage behavior; The policy delivery module is used to send the detection policy to the user terminal so that the user terminal can use the detection policy to remind the user of risky applications. The system receives a target non-preset application sent by the user terminal, detects the target non-preset application, and updates the detection strategy based on the detection results.

10. An electronic device, comprising: processor, and A memory configured to store computer-executable instructions, which, when executed, enable the processor to: The system obtains detection strategies for non-preset applications downloaded from a cloud server. The non-preset applications are those not downloaded through a pre-defined download channel. The cloud server sets different detection strategies based on relevant data generated by different related behaviors. The detection strategy is generated by the cloud server performing clustering operations on the risky applications based on the relevant data corresponding to the risky applications, extracting static and / or dynamic features of the risky applications from the relevant data of the risky applications corresponding to the clusters, and generating the strategy based on the static and / or dynamic features. When a user performs actions related to a target non-preset application through the user terminal, the relevant data of the target non-preset application is subjected to risk application detection operations according to the detection strategy. The relevant actions include application download behavior and application usage behavior. If the detection result indicates that the target non-preset application conforms to the risky application included in the detection strategy, the user is reminded of the risky application through the user terminal, and the target non-preset application is sent to the cloud server so that the cloud server can detect the target non-preset application and update the detection strategy based on the detection result.

11. An electronic device, comprising: processor, and A memory configured to store computer-executable instructions, which, when executed, enable the processor to: Acquire relevant data of non-preset applications collected by various terminal manufacturers from various user terminals. The non-preset applications are those that were not downloaded through the preset download channels. The relevant data includes at least the application download data. Perform risk detection operations on the relevant data to identify risky applications among the non-preset applications; Based on the relevant data corresponding to the risky applications, clustering operations are performed on the risky applications. Static and / or dynamic features of the risky applications are extracted from the relevant data of the risky applications corresponding to the clusters. Detection strategies for the risky applications are determined based on the static and / or dynamic features. The cloud server sets different detection strategies for relevant data generated based on different relevant behaviors, including application download behavior and application usage behavior. The detection strategy is sent to the user terminal so that the user terminal can use the detection strategy to remind the user of risky applications. The system receives a target non-preset application sent by the user terminal, detects the target non-preset application, and updates the detection strategy based on the detection results.

Images