An automated detection method for mobile application data security risks

Abstract

The embodiment of the specification provides a kind of mobile application data security risk automatic detection method, this method includes: based on the outgoing data packet of mobile application, access data of mobile application is obtained;Based on static information and access data, the abnormal behavior of mobile application is identified;Based on abnormal behavior, determine abnormal application;Based on access data, abnormal behavior and abnormal application, execute authority control.

Description

Technical Field

[0001] This specification relates to the field of information security technology, and in particular to an automated detection method for data security risks in mobile applications. Background Technology

[0002] With the widespread adoption of mobile devices, mobile operating systems typically manage mobile applications' access to sensors (such as microphones and cameras) and sensitive data (such as contacts and location information) through system permissions, relying on compliance with privacy policy statements. However, with the increasing complexity of mobile application architectures and the widespread embedding of third-party software development kits, the actual data collection, transmission, and usage behaviors of mobile applications are highly covert and dynamically changing.

[0003] Currently, data security protection mainly relies on static code analysis or coarse-grained pop-up blocking technology, but this is prone to problems such as the loss of key triggering conditions for privacy agreements, frequent false alarms due to asynchronous execution of front-end page state and underlying application programming interface, and the inability to effectively intercept hidden data operations.

[0004] Therefore, there is an urgent need for an automated detection method for mobile application data security risks to solve the problem of the difficulty in accurately aligning mobile application privacy protocols with underlying code behavior, and to improve the ability to identify and protect against asynchronous operations and covert data access, thereby overcoming the shortcomings of existing technologies in terms of accuracy, real-time performance and security isolation. Summary of the Invention

[0005] This specification provides one or more embodiments of an automated detection method for mobile application data security risks, characterized in that the method includes: obtaining access data of the mobile application based on outgoing data packets of the mobile application; identifying abnormal behavior of the mobile application based on static information and the access data; determining an abnormal application based on the abnormal behavior; and performing access control based on the access data, the abnormal behavior, and the abnormal application.

[0006] This specification provides one or more embodiments of an automated detection system for mobile application data security risks. The system comprises: an acquisition module configured to acquire access data of the mobile application based on outgoing data packets; an identification module configured to identify abnormal behavior of the mobile application based on static information and the access data; and to determine an abnormal application based on the abnormal behavior; and a control module configured to perform access control based on the access data, the abnormal behavior, and the abnormal application. Attached Figure Description

[0007] This specification will be further described by way of exemplary embodiments, which will be described in detail with reference to the accompanying drawings. These embodiments are not limiting; in these embodiments, the same reference numerals denote the same structures, wherein: Figure 1 This is an exemplary system block diagram of an automated detection system for mobile application data security risks, as shown in some embodiments of this specification. Figure 2 This is an exemplary flowchart of an automated detection method for mobile application data security risks, as shown in some embodiments of this specification. Figure 3 This is an exemplary schematic diagram illustrating the determination of over-privilege behavior according to some embodiments of this specification; Figure 4 This is another exemplary schematic diagram illustrating the determination of over-privilege behavior according to some embodiments of this specification; Figure 5 This is an exemplary flowchart illustrating the determination of sensitive behaviors according to some embodiments of this specification. Detailed Implementation

[0008] To more clearly illustrate the technical solutions of the embodiments in this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are merely some examples or embodiments of this specification. For those skilled in the art, these drawings can be applied to other similar scenarios without creative effort. Unless obvious from the context or otherwise specified, the same reference numerals in the drawings represent the same structures or operations.

[0009] It should be understood that the terms “system,” “device,” “unit,” and / or “module” used herein are one way to distinguish different components, elements, parts, sections, or assemblies at different levels. However, if other terms can achieve the same purpose, they may be replaced by other expressions.

[0010] As indicated in this specification and claims, unless the context clearly indicates otherwise, the words "a," "an," "an," and / or "the" do not specifically refer to the singular and may also include the plural. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of expressly identified steps and elements, which do not constitute an exclusive list, and the method or apparatus may also include other steps or elements.

[0011] Flowcharts are used in this specification to illustrate the operations performed by the system according to embodiments of this specification. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, the steps can be processed in reverse order or simultaneously. Furthermore, other operations can be added to these processes, or one or more steps can be removed from them.

[0012] Figure 1 This is an exemplary system block diagram of an automated detection system for mobile application data security risks, as shown in some embodiments of this specification.

[0013] In some embodiments, the automated detection system 100 for mobile application data security risks may include an acquisition module 110, an identification module 120, and a control module 130.

[0014] In some embodiments, one or more modules of the automated detection system 100 for mobile application data security risks may be integrated on the processor.

[0015] The processor can process data and / or information obtained from other devices or system components. Based on this data, information, and / or processing results, the processor can execute program instructions to perform one or more functions described in this application. For example, the processor can obtain access data of a mobile application based on outgoing data packets from the mobile application. In some embodiments, the processor may include one or more sub-processing devices (e.g., a single-core processing device or a multi-core multi-chip processing device). By way of example only, the processor may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), a microprocessor, or any combination thereof.

[0016] The acquisition module 110 is the module responsible for collecting and extracting access data during the operation of the mobile application from the outgoing data packets.

[0017] In some embodiments, the acquisition module 110 is configured to acquire access data of the mobile application based on the outgoing data packets of the mobile application.

[0018] In some embodiments, the acquisition module 110 is further configured to: intercept sensitive access requests initiated by the mobile application.

[0019] In some embodiments, the acquisition module 110 is further configured to: intercept sensitive access requests initiated by the mobile application; capture the active page and page structure data of the mobile application, construct a jump path, and determine the access page.

[0020] The identification module 120 refers to the module that identifies abnormal behavior and determines abnormal applications.

[0021] In some embodiments, the identification module 120 is configured to: identify abnormal behavior of a mobile application based on static information and access data; and determine the abnormal application based on the abnormal behavior.

[0022] In some embodiments, the identification module 120 is further configured to determine whether the mobile application exhibits unauthorized behavior.

[0023] In some embodiments, the identification module 120 is further configured to: determine a first feature vector based on a privacy protocol; determine a second feature vector based on the actual calling permissions corresponding to the sensitive access request; calculate the similarity between the first feature vector and the second feature vector; and determine that there is unauthorized behavior in response to the similarity being less than a similarity threshold.

[0024] In some embodiments, the identification module 120 is further configured to: parse the privacy protocol into corresponding assertion statements; perform path analysis on the program code of the mobile application, extract the program control flow subgraph and trigger constraint equations leading to the sensitive interface trigger point; invert the assertion statements as constraint boundaries, perform a logical AND operation with the program control flow subgraph and trigger constraint equations, and then perform logical solution verification to obtain the verification result; in response to the verification result indicating the existence of a violation path, extract the violation code line number, and determine the existence of unauthorized behavior based on the violation code line number.

[0025] In some embodiments, the identification module 120 is further configured to determine whether the mobile application exhibits sensitive behavior.

[0026] In some embodiments, the identification module 120 is further configured to: identify whether the function called in response to the sensitive access request belongs to a preset set of sensitive functions; in response to the function being called belonging to the set of sensitive functions, match the semantics of the function being called with the semantics of the accessed page; in response to the semantics of the function being called not matching the semantics of the page, preliminarily determine that there is sensitive behavior.

[0027] In some embodiments, after initially determining that sensitive behavior exists, the identification module 120 is further configured to: obtain a click semantic sequence, the click semantic sequence including at least one page click event and the corresponding operation semantics; trace back the operation records within the time window before the function is called; and in response to finding a page click event that matches the semantics of the function within the time window, determine that the function is an asynchronous and legal call; otherwise, confirm that sensitive behavior exists.

[0028] The control module 130 refers to the module that controls the execution permissions of abnormal applications.

[0029] In some embodiments, the control module 130 is configured to perform permission control based on access data, abnormal behavior, and abnormal applications.

[0030] In some embodiments, the control module 130 is further configured to: statistically analyze the frequency characteristics of abnormal behavior within a preset time window; generate a first control instruction with a corresponding control strength value based on the frequency characteristics, wherein the first control instruction is configured to restrict abnormal applications from reading target data; statistically analyze the discretization degree of target network parameters within the preset time window; determine interception parameters based on the discretization degree; and control the associated gateway device to intercept the target data based on the interception parameters.

[0031] In some embodiments, the control module 130 is further configured to: determine whether the program interface that caused the abnormal behavior reads preset sensitive information; in response to the program interface reading the preset sensitive information, intercept the first control instruction; and generate and send a second control instruction based on the program interface, wherein the second control instruction is configured to return simulation data for the reading operation of the preset sensitive information.

[0032] In some embodiments, the control module 130 is further configured to perform isolation operations on the data acquisition behavior of abnormal applications.

[0033] In some embodiments, the control module 130 is further configured to: in response to an abnormal application issuing a data acquisition request, redirect the path in the data transmission link to redirect the acquired raw data stream to a buffer; pre-analyze the raw data stream in the buffer to identify whether it contains privacy information, and continuously detect the access page of the abnormal application; and in response to the raw data stream not containing privacy information and the access page being accessed being a compliance trigger page, release the raw data stream to the abnormal application.

[0034] For further explanation of the above content, please refer to [link / reference]. Figures 2 to 5 And its related descriptions.

[0035] It should be understood that Figure 1 The system and its modules shown can be implemented in various ways.

[0036] It should be noted that the above description of the automated detection system and its modules for mobile application data security risks is for convenience only and should not be construed as limiting this specification to the scope of the embodiments described. It is understood that those skilled in the art, after understanding the principles of the system, may arbitrarily combine the various modules or construct subsystems connected to other modules without departing from these principles. In some embodiments, Figure 1 The acquisition module, identification module, and control module disclosed herein can be different modules within a single system, or a single module can implement the functions of two or more of the aforementioned modules. For example, the modules can share a single storage module, or each module can have its own separate storage module. Such variations are all within the scope of protection of this specification.

[0037] Figure 2 This is an exemplary flowchart of an automated detection method for mobile application data security risks, based on some embodiments of this specification. Figure 2 As shown, process 200 includes steps 210-240 as described below. In some embodiments, process 200 may be executed by a processor. For more information about processors, see [link to relevant documentation]. Figure 1 And its related descriptions.

[0038] Step 210: Obtain the access data of the mobile application based on the outgoing data packets of the mobile application.

[0039] Mobile applications are third-party software programs installed and running on a mobile operating system. Examples include navigation apps, video apps, and reading apps. A mobile operating system is a software system that manages the hardware resources of a mobile terminal and provides the runtime environment and basic services for mobile applications. Examples include Android and iOS.

[0040] In some embodiments, the processor uses the process manager or package manager of the mobile operating system to lock onto the target process that is currently running in the foreground or active in the background, and identifies it as a mobile application.

[0041] Outgoing data packets refer to the data streams sent by mobile applications to external servers through network interfaces. Examples include Hypertext Transfer Protocol (HTTP) request messages, Transmission Control Protocol (TCP) segments, and User Datagram Protocol (UDP) datagrams.

[0042] Access data refers to the dataset generated by a mobile application during its operation, consisting of information related to resource requests, network communications, or page states. For example, access data may include the target Internet Protocol (IP) address, port number, and the requested device identifier.

[0043] In some embodiments, the processor disassembles the IP header and transport layer message of the outgoing data packet, serializes the extracted parameters into a structure / JSON dataset, and uses it as access data.

[0044] In some embodiments, the processor obtains access data from the mobile application by intercepting sensitive access requests initiated by the mobile application.

[0045] Sensitive access requests refer to requests made by a mobile application during runtime that attempt to access user privacy resources through underlying Application Programming Interfaces (APIs). For example, a request to call the LocationManager.requestLocationUpdates() API to obtain user location information can be considered a sensitive access request.

[0046] User privacy resources refer to sensitive data in a mobile operating system that requires explicit user authorization to access. Examples include device identifiers (such as IMEI), location information, contacts, SMS records, camera and microphone data, etc.

[0047] In some embodiments, the processor may obtain the signature of the method currently being executed by the mobile application and match the method signature with a high-risk API library stored locally. During the matching process, the method signature is calculated using a preset hash function to obtain the corresponding hash value, and the hash value is compared with the hash value in the high-risk API library. When a match is found, the current call request is determined to be a sensitive access request, and the corresponding call stack information is further extracted for subsequent behavior analysis and risk assessment.

[0048] A high-risk API library refers to a database of pre-built and stored sensitive interface features. In some embodiments, the high-risk API library is pre-defined by those skilled in the art.

[0049] In some embodiments, the high-risk API library stores predefined sensitive API characteristic information in the form of a database (e.g., an SQLite data table).

[0050] In some embodiments, the processor can intercept sensitive access requests in various ways. For example, it can dynamically intercept low-level APIs by deploying an eBPF (Extended Berkeley Packet Filter) program in kernel space. Another example is inserting an interception layer using a dynamic proxy mechanism. Yet another example is intercepting calls at the kernel level using the mobile operating system.

[0051] In some embodiments, the processor's acquisition of access data from the mobile application further includes: intercepting sensitive access requests initiated by the mobile application; capturing the mobile application's active page and page structure data, constructing a jump path, and determining the accessed page.

[0052] An active page refers to the page instance that a mobile application is currently displaying or that the user is interacting with. For example, in a chat application, it is the page instance corresponding to the chat window that the user is currently viewing.

[0053] A page instance is an object corresponding to a specific page in a mobile application. It is responsible for managing the page's lifecycle, user interface (UI) components, and user interaction logic. In some embodiments, when a page instance is in the foreground and receives screen focus, it becomes the active page that the user can directly interact with.

[0054] Page structure data refers to the collection of hierarchical information and control attribute text of all UI components that make up the elements displayed on an active page. For example, page structure data can be a Document Object Model (DOM) tree laid out in Extensible Markup Language (XML) that contains nodes such as text display controls (TextView), button controls (Button), and image controls (ImageView), as well as the text description, position coordinates, and attribute information of each node.

[0055] In some embodiments, the processor may invoke the underlying window manager of the mobile operating system to extract the top-level window or page with the attribute flag "FocusedWindow==true" as the active page.

[0056] In some embodiments, the processor sends a traversal instruction to the root view of the active page, recursively accesses all child control nodes on the page, reads the text description, position coordinates and attribute information of each child control node, and then serializes the collected data of all child control nodes into a document string in XML or JSON format to generate complete page structure data.

[0057] A navigation path refers to a sequence of pages visited sequentially by the user or application logic during the operation of a mobile application. For example, if a user enters the user profile page from the mobile application's homepage and then enters the privacy settings page, the corresponding navigation path can be represented as: [Homepage, User Profile Page, Privacy Settings Page].

[0058] In some embodiments, the jump path can be used to describe the navigation trajectory and operation flow between different pages.

[0059] In some embodiments, the processor registers listeners (such as ActivityLifecycleCallbacks) in the lifecycle management service of the mobile application, captures the class names of active pages in real time, and stores them sequentially into a linked list structure in memory according to timestamp order, thereby constructing a jump path.

[0060] The accessed page refers to the page the user is currently on when a mobile application initiates a sensitive access request.

[0061] In some embodiments, the processor extracts the timestamp of the mobile operating system when the "sensitive access request is intercepted", performs a binary search in the jump path, and selects the most recent active page that has not been destroyed as the access page.

[0062] Step 220: Identify abnormal behavior of the mobile application based on static information and access data.

[0063] Static information refers to predefined data that is embedded in the installation package before a mobile application runs, or that is publicly declared in text form. Examples include the AndroidManifest.xml file and privacy agreements.

[0064] In some embodiments, the processor determines static information by parsing firmware files in the mobile application's installation package and extracting text from publicly disclosed statements.

[0065] Fixed files refer to fixed resource files that are pre-written in the mobile application installation package, do not depend on runtime state, and can be read through static parsing. Examples include manifest files, resource files, and configuration files.

[0066] Publicly disclosed texts refer to the standardized text content that mobile applications publicly display to users, explaining their rules regarding permissions, data collection, and service. Examples include privacy policies, service agreements, and permission usage instructions.

[0067] In some embodiments, static information includes a privacy agreement.

[0068] A privacy policy is a set of rules that an application developer publicly displays to users, outlining the rules for data collection, use, and protection. In some embodiments, the privacy policy is pre-installed by the application developer within the mobile application's installation package.

[0069] Abnormal behavior refers to actions taken by a mobile application during runtime that violate its public statements or exceed the boundaries of reasonable user authorization. Examples include unauthorized access to the address book or silent background access to location information.

[0070] In some embodiments, the processor can determine whether an actual operation is abnormal by comparing it with static information during mobile application runtime. In some embodiments, the processor uses the target network parameter in the access data as the primary key to query the publicly declared compliant domain names or IP whitelists of the mobile application in the static information; if the query result is empty, the outbound operation is marked as abnormal behavior. For more information on the target network parameter, please refer to the relevant description below.

[0071] In some embodiments, abnormal behavior includes unauthorized behavior.

[0072] Excessive privilege behavior refers to the behavior of a mobile application that, during its operation, actually invokes permissions that exceed the scope of its privacy agreement.

[0073] In some embodiments, anomalous behavior also includes sensitive behavior.

[0074] Sensitive behavior refers to malicious data collection actions that are disconnected from the page displayed on the front end of a mobile application's resource access action.

[0075] In some embodiments, the processor identifies abnormal behavior of a mobile application based on static information and access data, including determining whether the mobile application engages in unauthorized behavior.

[0076] For more information on how to determine if a mobile application is engaging in unauthorized behavior, please see [link to relevant documentation]. Figure 3 and Figure 4 And its related descriptions.

[0077] In some embodiments, the processor, based on static information and access data, identifies anomalous behavior of a mobile application by further determining whether the mobile application exhibits sensitive behavior.

[0078] For more information on how to determine if a mobile application exhibits sensitive behavior, please see [link to relevant documentation]. Figure 5 And its related descriptions.

[0079] Step 230: Based on the abnormal behavior, identify the abnormal application.

[0080] An abnormal application refers to a mobile application entity that performs abnormal behavior during operation. For example, a malicious game application that is illegally uploading clipboard content.

[0081] In some embodiments, when an abnormal behavior determination is triggered, the processor will read the network connection state table (such as / proc / net / tcp), and look up the corresponding process's User Identifier (UID) based on the port number used by the abnormal behavior, thereby accurately locating the mobile application instance that initiated the violation and determining that the mobile application is an abnormal application.

[0082] A network connection status table is a collection of current network connection information maintained by a mobile operating system.

[0083] In some embodiments, a mobile application is assigned a unique UID upon installation to isolate resource access permissions for different mobile applications; different components of the same mobile application share the same UID, while different mobile applications have different UIDs, thereby enabling the differentiation of mobile application identities and the control of permissions.

[0084] Step 240: Perform access control based on access data, abnormal behavior, and abnormal applications.

[0085] Access control refers to mandatory intervention measures taken against abnormal applications, such as restricting their resource access or data transmission. Examples include disconnecting network connections and blocking read requests.

[0086] In some embodiments, the processor can perform access control in a variety of ways. For example, it can perform permission verification, intercept abnormal behavior, prompt the user, or directly block access to resources.

[0087] In some embodiments, the accessed data includes target network parameters.

[0088] Target network parameters refer to network routing and location identification information used to identify the final recipient of the data. In some embodiments, target network parameters may include the IP address (e.g., 192.168.1.1) and port number (e.g., 8080 or 443) of the target server.

[0089] In some embodiments, the processor can obtain target network parameters by reading a fixed offset from the outgoing data packet to be sent from the buffer, extracting the target IP address from the IPv4 / IPv6 header, and the target port from the TCP / UDP header. The fixed offset refers to a fixed number of bytes in the buffer from a known starting position to the location of the target field. In some embodiments, the fixed offset can be determined according to the network protocol standard used (such as IPv4, IPv6, UDP, TCP, etc.).

[0090] In some embodiments, the processor performs access control based on access data, abnormal behavior, and abnormal applications, including: statistically analyzing the frequency characteristics of abnormal behavior within a preset time window; generating a first control instruction with a corresponding control strength value based on the frequency characteristics, wherein the first control instruction is configured to restrict abnormal applications from reading target data; statistically analyzing the discretization degree of target network parameters within a preset time window; determining interception parameters based on the discretization degree; and controlling associated gateway devices to intercept target data based on the interception parameters.

[0091] Frequency characteristics refer to quantitative values ​​that describe the density of abnormal applications initiating illegal operations per unit of time.

[0092] In some embodiments, the processor calculates a specific frequency value as a frequency feature by counting the total number of abnormal behaviors within a preset time window and dividing it by the length of the preset time window.

[0093] A preset time window refers to a fixed time range that is set in advance. For example, 10 seconds, 30 seconds, 1 minute, etc. In some embodiments, the length of the preset time window is set by those skilled in the art.

[0094] A control strength value indicates the level of severity a mobile operating system should apply when implementing blocking or restrictions. In some embodiments, the control strength value can be a discrete step variable. For example, the control strength value can be: Level 1, Level 2, Level 3.

[0095] In some embodiments, different levels represent different levels of control intensity and correspond to different actions. For example, the action corresponding to level 1 may be API rate limiting and speed reduction; the action corresponding to level 2 may be providing fake data to deceive users; and the action corresponding to level 3 may be directly killing the process or physically shutting down the hardware.

[0096] In some embodiments, the processor can determine the current control strength value based on the current frequency characteristics by querying a frequency-control strength value preset table.

[0097] The frequency-control intensity value preset table includes multiple sets of correspondences between frequency characteristics and control intensity values. In some embodiments, the frequency-control intensity value preset table can be manually preset.

[0098] In some embodiments, the processor may determine the intensity control threshold based on frequency characteristics and a first threshold and a second threshold, wherein the first threshold is less than the second threshold.

[0099] In some embodiments, when the frequency feature is less than a first threshold, the corresponding control strength value is determined to be 1; when the frequency feature is between the first threshold and the second threshold, the corresponding control strength value is determined to be 2; and when the frequency feature is greater than the second threshold, the corresponding control strength value is determined to be 3.

[0100] In some embodiments, the first threshold and the second threshold are determined based on the frequency ratio between the call frequency of the hardware access channel corresponding to the abnormal application and the sending frequency of the outgoing data packet corresponding to the abnormal application.

[0101] A hardware access channel refers to the path through which device hardware resources are accessed to obtain data via a bus or peripheral interface.

[0102] In some embodiments, if the frequency ratio is within a preset ratio range, a manually preset first threshold and a second threshold are used; if the frequency ratio is outside the preset ratio range, the first threshold and the second threshold are determined based on the degree of deviation. In some embodiments, when the frequency ratio is outside the preset ratio range, the first threshold and the second threshold are negatively correlated with the degree of deviation. For example, the processor can determine the first threshold using the following formula (1). Second threshold : (1) In formula (1), and These represent the baseline values ​​for the first threshold and the second threshold, respectively. Indicates the degree of deviation; α and β are adjustment coefficients, whose values ​​are preset manually and satisfy α>0, β>0.

[0103] In some embodiments, and A preset first threshold and a preset second threshold can be used when the frequency ratio is within a preset ratio range.

[0104] The preset ratio range refers to the normal fluctuation range of the ratio between the "frequency of hardware access channel calls" and the "frequency of outgoing data packets sent" of a mobile application under normal operating conditions. In some embodiments, the preset ratio range may be set by those skilled in the art based on experience.

[0105] The degree of deviation refers to the difference between the actual detected frequency ratio and the boundary of the preset ratio range. For example, if the actual detected frequency ratio is 1.5 and the preset ratio range is [1, 1.2], then the degree of deviation is 1.5 - 1.2 = 0.3.

[0106] For example, taking location information as an example, when a normal navigation application is running in the background, its location reading frequency (the frequency of calling the hardware access channel) and location information reporting frequency (the frequency of sending outgoing data packets) remain in the ratio range [1, 1.2]. The corresponding preset first threshold is 10 times / second, the second threshold is 50 times / second, and α and β are both 2. If it is detected that a mobile application is in the background and the ratio between its location reading frequency and location information reporting frequency is 1.5, deviating from the range [1, 1.2], the deviation degree is 0.3. Through formula (1), the adjusted first threshold is 9.4 times / second, and the second threshold is 49.4 times / second.

[0107] In some embodiments of this specification, when the frequency ratio is within a preset ratio range, the mobile application is determined to be working normally; when the frequency ratio is outside the preset ratio range, the mobile application is determined to have a high risk of abnormality, and the judgment criteria for abnormal behavior are tightened by correspondingly lowering the first threshold and the second threshold.

[0108] The first control instruction refers to an instruction that cuts off the hardware access channel of an abnormal application at the kernel level of the mobile operating system, thereby controlling the abnormal application. For example, the first control instruction can be an eBPF bytecode with a token bucket rate limiting parameter, used to limit the application to reading the photo album a maximum of once per minute.

[0109] In some embodiments, the processor determines the corresponding control strength value based on the frequency characteristics of the statistically observed abnormal behavior, and then generates a corresponding first control instruction based on the action corresponding to the control strength value.

[0110] In some embodiments, when the abnormal behavior involves unauthorized access to the positioning function, the first control instruction includes an instruction to restrict the hardware access channel of the positioning module to block the abnormal application from obtaining geographical location information; when the abnormal behavior involves unauthorized access to the microphone function, the first control instruction includes an instruction to restrict the hardware access channel of the microphone to block the abnormal application from obtaining audio signals; when the abnormal behavior involves unauthorized access to the camera function, the first control instruction includes an instruction to restrict the hardware access channel of the camera to block the abnormal application from obtaining images or videos; when the abnormal behavior involves unauthorized file access, the first control instruction includes an instruction to restrict the hardware access channel of the corresponding file to block the abnormal application from reading or writing to the file.

[0111] Target data refers to user privacy resources that abusive applications attempt to access and send. Examples include a user's photo album, contacts, and clipboard content.

[0112] In some embodiments, the processor may restrict abnormal applications from reading target data based on a first control instruction.

[0113] Discretization refers to the degree of dispersion, disorder, or random variation of the target addresses of external networks that a mobile application attempts to connect to within the IP address space. The IP address space is the set of all target IP addresses.

[0114] In some embodiments, the processor obtains the degree of discretization of the target network parameters by performing statistical algorithms on the target network parameters. For example, the processor calculates the standard deviation of the integer values ​​of each target address and uses the standard deviation as the degree of discretization; a larger standard deviation indicates a wider distribution of target addresses. Alternatively, the processor can use information entropy to measure the randomness of the target address distribution and use the entropy value as the degree of discretization; a higher entropy value indicates a more chaotic and irregular distribution of target addresses.

[0115] Interception parameters refer to the set of routing blocking rules sent by the processor to the associated gateway device. In some embodiments, interception parameters may include precise blocking rules and generalized blocking rules.

[0116] Precise blocking rules refer to routing blocking rules that precisely block access to a single specific IP address. For example, DROP IP=114.1.1.1.

[0117] A generalized blocking rule is a route blocking rule that blocks routes in bulk across an entire IP network segment. For example, DROPSUBNET=114.1.0.0 / 16.

[0118] In some embodiments, the processor determines the blocking parameters based on the current degree of discretization and a discretization threshold. In some embodiments, if the degree of discretization is less than the discretization threshold, a precise blocking rule is used; if the degree of discretization is greater than the discretization threshold, a generalized blocking rule is used. The discretization threshold is set by those skilled in the art based on experience.

[0119] The associated gateway device refers to the network exit device that a mobile application passes through when sending outgoing data packets after obtaining target data.

[0120] In some embodiments, the processor controls the associated gateway device to intercept target data based on interception parameters. When an abnormal application attempts to send out TCP or UDP packets containing target data, the associated gateway device extracts the target IP address of the outgoing packet and matches it with the current interception parameters. If the match is successful, the associated gateway device either discards the outgoing packet directly or returns a TCP reset packet to the source to terminate the connection, thereby achieving effective interception of the target data.

[0121] For example, if an abnormal application attempts to send a TCP packet with a target IP address of 114.1.1.1, the processor will match the target IP address with the current blocking parameters. If the current blocking parameters are for exact blocking, it will determine whether the two IP addresses are exactly the same; if they are, the associated gateway device will either discard the packet directly or send a TCP reset packet to the source to terminate the connection. If the current blocking parameters are for generalized blocking, it will determine whether the target IP address belongs to the network segment specified by the rule; if it does, the packet will also be blocked, thus achieving the interception of the target data.

[0122] In some embodiments of this specification, by statistically analyzing the frequency characteristics of abnormal behavior within a preset time window and generating a first control instruction with a corresponding control strength value, abnormal applications are restricted from reading target data. At the same time, the discretization degree of the target network parameters is statistically analyzed to determine the interception parameters and control the associated gateway device to intercept the target data. In this way, on the one hand, the channel for abnormal applications to obtain sensitive data is cut off, and on the other hand, the outward transmission channel of the already obtained data is blocked, thereby achieving dual anti-leakage blocking of abnormal behavior of mobile applications and improving the rigor and security of data security management.

[0123] In some embodiments, the processor performs access control based on access data, abnormal behavior, and abnormal applications, and further includes: determining whether the program interface that caused the abnormal behavior reads preset sensitive information; intercepting a first control instruction in response to the program interface reading the preset sensitive information; and generating and sending a second control instruction based on the program interface. The second control instruction is configured to return simulation data upon the read operation of the preset sensitive information.

[0124] It is known that determining whether a program interface that triggers abnormal behavior reads preset sensitive information includes two scenarios: the program interface that triggers abnormal behavior reads preset sensitive information and the program interface that triggers abnormal behavior does not read preset sensitive information.

[0125] A program interface (API) refers to the entry point through which a mobile application accesses system resources or data. Examples include interfaces for reading clipboard content, obtaining location information, or accessing stored data.

[0126] Program interfaces that trigger abnormal behavior are those that cause mobile applications to perform out-of-bounds, unauthorized, or unauthorized operations. For example, program interfaces that cause unauthorized recording behavior include: / dev / snd / pcm or AudioRecord.startRecording().

[0127] In some embodiments, the processor can determine the program interface that caused the abnormal behavior by querying the system log.

[0128] Pre-defined sensitive information refers to pre-defined data information that needs to be protected. In some embodiments, pre-defined sensitive information may include, but is not limited to, at least one of the following: (1) User identity data: such as username, password, ID card number, mobile phone number, contacts in address book and user fingerprints, etc.; (2) Device hardware and location data: such as International Mobile Equipment Identity (IMEI), Media Access Control Address (MAC) address, geographic location information (GPS coordinates), base station positioning data, etc.; (3) Multimedia and file data: such as local album photos, microphone recording files, camera live images, clipboard content, user private documents, etc.; (4) Application interaction data: such as chat logs, transaction vouchers, browsing history, etc.

[0129] In some embodiments, the preset sensitive information may be preset manually.

[0130] In some embodiments, the processor can identify whether the data stream of the program interface that caused the abnormal behavior contains preset sensitive information by means of regular expression matching, keyword recognition, or data fingerprint comparison.

[0131] In some embodiments, the processor may withdraw, suspend, or discard the first control instruction from the execution queue before it takes effect, thereby intercepting the first control instruction.

[0132] The second control command refers to the command that provides simulation data feedback for the reading operation of preset sensitive information.

[0133] In some embodiments, the second instruction can be implemented as a bytecode program for modifying the return value of a system call, based on an extended Berkeley packet filter. When a program interface that triggers abnormal behavior is detected reading preset sensitive information, the processor dynamically generates a second control instruction and converts it into a control logic block or eBPF bytecode program that can be executed at the kernel level. The entire generation process is completed in real time during the mobile application runtime, thereby achieving dynamic protection for each sensitive information access operation. This ensures that, without interrupting the normal execution of the program, the read operation for abnormal behavior returns simulation data, effectively avoiding the actual leakage of sensitive information.

[0134] A read operation refers to the process by which a mobile application obtains system resources or data through a program interface, including actively calling the program interface to obtain data and passively receiving data returned by the program interface.

[0135] Simulated data refers to data that replaces real sensitive information returned to a mobile application. In some embodiments, simulated data has the same format as real sensitive information, but its actual content is entirely blank, anonymized, or randomly generated, making it a fake data body. For example, simulated data could be a fake MAC address string with the content 00:00:00:00:00:00. Another example is a JSON address book list containing only empty nodes with a length of 0.

[0136] In some embodiments, when the second control instruction intercepts a read operation of target data at the underlying hook point, the processor can request a fake buffer in the mobile operating system and fill it with a preset random number generator or null template. Subsequently, the memory pointer in the mobile application process, which was originally used to receive real data, is modified to point to the fake buffer, thereby enabling the read operation of preset sensitive information to return simulated data.

[0137] In some embodiments of this specification, by intercepting the first control instruction when the program interface is detected to involve reading preset sensitive information, and generating a second control instruction based on the program interface for returning simulation data, the processor can effectively protect sensitive information without directly blocking application behavior. On the one hand, this avoids functional abnormalities that may be caused by directly restricting the mobile application's read operations, improving the compatibility of the mobile application; on the other hand, by replacing the returned data with simulation data, the leakage path of sensitive information is blocked at the source, enhancing data security protection capabilities, thereby achieving a balance between security and usability.

[0138] In some embodiments, the processor, based on access data, abnormal behavior, and abnormal applications, may further perform access control by performing isolation operations on the data acquisition behavior of abnormal applications.

[0139] Data acquisition behavior refers to the behavior of mobile applications in acquiring data through program interfaces or network requests.

[0140] In some embodiments, the processor may register a listener on the communication bus of the mobile operating system to monitor the read operations of the mobile application process in real time, thereby identifying data acquisition behavior.

[0141] Isolation operation refers to the intermediate isolation of the data acquisition process without directly blocking the data acquisition behavior, so that the data stream enters a controlled environment for detection and judgment before being transmitted to the mobile application, thereby achieving delayed release or conditional release of the data stream.

[0142] In some embodiments, the isolation operation includes: in response to an abnormal application issuing a data acquisition request, performing path redirection on the data transmission link to redirect the acquired raw data stream to a buffer; pre-analyzing the raw data stream in the buffer to identify whether it contains privacy information and continuously detecting the access page of the abnormal application; and in response to the raw data stream not containing privacy information and the access page being accessed being a compliance trigger page, releasing the raw data stream to the abnormal application.

[0143] For more information about the page you are visiting, see step 210 and its related description.

[0144] The known abnormal references include two cases: issuing a data retrieval request and not issuing a data retrieval request.

[0145] It is known that pre-analysis of the raw data stream within the buffer is performed to identify whether it contains privacy information, including two cases: the raw data stream contains privacy information and the raw data stream does not contain privacy information.

[0146] A data retrieval request refers to a data access request initiated by an abnormal application through a program interface or network interface.

[0147] A data transmission link refers to the physical and logical channel established during data transmission to ensure reliable data transmission.

[0148] Path redirection refers to the operation of changing the data pointer that was originally about to be written to the virtual memory space of a mobile application to point to a controllable physical memory space.

[0149] A raw data stream refers to a sequence of binary raw payload bytes that has not undergone any scaling, desensitization, or encryption. For example, a raw data stream could be a stream of raw camera images containing all Exchangeable Image File Format (EXIF) information and without any compression.

[0150] In some embodiments, when a data acquisition action occurs, the processor can perform a block copy to read the original data stream from the memory address of the buffer after path redirection.

[0151] A buffer is a storage area used to temporarily store raw data streams.

[0152] In some embodiments, in response to a data acquisition request issued by an abnormal application, the processor performs path redirection on the transmission link of the original data. That is, in the kernel-mode data processing flow of the mobile operating system, the data access path that was about to be written to the virtual memory space of the abnormal application is intercepted, and the corresponding data pointer is redirected to the buffer, so that the original data stream encapsulated by the underlying layer of the mobile operating system is written to the buffer for temporary storage.

[0153] Pre-analysis refers to the analysis, processing, and detection of the raw data stream within the buffer.

[0154] Privacy information refers to sensitive plaintext content involving user secrets that is mixed in with the raw data stream. For example, the photographer's precise latitude and longitude information hidden in the EXIF ​​data area of ​​a photo, or the 18-digit ID number information in a screenshot.

[0155] In some embodiments, the processor identifies privacy information through regular expression matching. For example, the processor identifies sensitive plaintext content as privacy information by matching ID card numbers (\d{18}), mobile phone numbers (1[3-9]\d{9}), landline phone numbers (\d{3,4}-\d{7,8}), or EXIF ​​latitude and longitude information (GPS\:\s*[-+]?\d{1,3}\.\d+,\s*[-+]?\d{1,3}\.\d+).

[0156] A compliance trigger page refers to a page within a mobile application that is designed by the developer for legitimate business scenarios and whose functionality requires access to user data.

[0157] Releasing the original data stream means re-introducing the original data stream in the buffer into the original data transmission link and transmitting it to the abnormal application so that it can complete the data acquisition behavior.

[0158] In some embodiments of this specification, by redirecting the data transmission link and pre-analyzing and determining whether the original data stream contains privacy information in a buffer, the processor can perform fine-grained control over the content of the original data stream without affecting the integrity of the data acquisition behavior. The original data stream is only released when it is confirmed that it does not contain privacy information and the access scenario is compliant, thereby effectively preventing the leakage of privacy information and reducing interference with the normal functioning of mobile applications.

[0159] In some embodiments of this specification, access data is obtained and abnormal behavior is identified based on the outgoing data packets of the mobile application, and permission control is performed on the abnormal application to cut off the hardware access channel. At the same time, by combining the access data and abnormal behavior, the outgoing data packets of the associated gateway device are controlled to achieve dual protection against the illegal behavior of the mobile application and greatly improve the rigor of mobile application data security risk management.

[0160] Figure 3 This is an exemplary schematic diagram illustrating the determination of over-privilege behavior according to some embodiments of this specification.

[0161] In some embodiments, the processor determines whether a mobile application has engaged in unauthorized behavior by: determining a first feature vector based on a privacy protocol; determining a second feature vector based on the actual calling permissions corresponding to a sensitive access request; calculating the similarity between the first feature vector and the second feature vector; and determining that unauthorized behavior exists in response to a similarity threshold.

[0162] For more information on privacy policies, sensitive access requests, and unauthorized behavior, please see [link to relevant documentation]. Figure 2 And its related descriptions.

[0163] The first feature vector refers to the dense array of real numbers formed in a multi-dimensional space after the privacy protocol has been processed by the word embedding model. The word embedding model can be either the Word2Vec model or the BERT model.

[0164] In some embodiments, the processor can input a privacy protocol into a pre-deployed word embedding model, and after forward propagation computation via the word embedding model, obtain a real number array of a specified dimension, and use this real number array as a first feature vector.

[0165] Actual access permissions refer to the permission classification constants triggered at the underlying layer of the mobile operating system for sensitive access requests.

[0166] In some embodiments, the processor can parse the API method name in a sensitive access request, perform a matching query in the API-permission mapping table, obtain the permission constant string corresponding to the API method name, and determine the permission constant string as the actual call permission.

[0167] Permission constant strings are string-based permission identifiers used to uniquely identify a specific permission type.

[0168] In some embodiments, the API-permission mapping table includes multiple sets of mappings between API method names and permission constant strings. In some embodiments, the API-permission mapping table may be preset by those skilled in the art.

[0169] The second vector refers to a dense array of real numbers in a multidimensional space representing the natural language description of the actual invocation permissions.

[0170] In some embodiments, the processor can map the actual calling permissions corresponding to the sensitive access request to a semantic description, input the semantic description into a pre-deployed word embedding model, and obtain a real number array with a specified dimension after forward propagation calculation through the word embedding model, and determine the real number array as the second feature vector.

[0171] Semantic description refers to converting permission constant strings into human-readable natural language text. For example, converting a location-related permission constant string into the text "Get precise geographic location information".

[0172] In some embodiments, the processor uses the actual access permissions as search keywords to search a preset database and outputs a semantic description. The preset database refers to a database containing the correspondence between multiple sets of permission constant strings and semantic descriptions. In some embodiments, the preset database is set by those skilled in the art.

[0173] In some embodiments, the processor can calculate the similarity between the first feature vector and the second feature vector using a similarity calculation method. Similarity calculation methods include, but are not limited to, cosine similarity, Euclidean distance, etc.

[0174] The similarity threshold is a threshold used to measure the degree of similarity between the first feature vector and the second feature vector in the semantic space.

[0175] There are two known cases: similarity less than the similarity threshold and similarity not less than the similarity threshold.

[0176] In some embodiments, the processor determines that there is unauthorized behavior in response to a similarity score less than a similarity threshold.

[0177] In some embodiments of this specification, by mapping the privacy protocol and the actual access permissions to feature vectors and calculating their similarity, automatic determination of unauthorized behavior is achieved. This overcomes the coarse-grained control of traditional methods that rely solely on static permission tables, and provides a precise, fine-grained, and automated compliance detection method, effectively improving the level of protection for mobile application data security and user privacy.

[0178] While feature vector similarity methods can quickly screen for potential unauthorized behaviors, they rely solely on surface semantics and struggle to uncover deeply hidden violations. Therefore, the processor can employ an alternative approach to determine unauthorized behavior.

[0179] Figure 4 This is another exemplary schematic diagram illustrating the determination of over-privilege behavior according to some embodiments of this specification.

[0180] In some embodiments, the processor determining whether a mobile application exhibits unauthorized behavior further includes: parsing the privacy protocol into corresponding assertion statements; performing path analysis on the mobile application's program code to extract the program control flow subgraph and trigger constraint equations leading to sensitive interface trigger points; inverting the assertion statements as constraint boundaries, performing a logical AND operation with the program control flow subgraph and trigger constraint equations, and then performing logical solution verification to obtain a verification result; in response to the verification result indicating the existence of a violation path, extracting the violation code line number, and determining the existence of unauthorized behavior based on the violation code line number.

[0181] Assertion statements are structured conditional codes that transform long texts into computer-generated formal verification and logical reasoning.

[0182] In some embodiments, the processor parses the privacy protocol into corresponding assertion phrases by invoking a large language model (such as GPT, Gemini, etc.).

[0183] Path analysis refers to a static scanning technique that deduces all possible branches of program code execution using mathematical graph theory without actually running the program. For example, a processor uses a symbolic execution engine (such as the Soot framework) to parse the "program code" into an Abstract Syntax Tree (AST) and an Intermediate Representation (IR). Starting from the main entry point of a mobile application (such as MainActivity.onCreate), it simulates the instruction pointer traversing all execution sequences with jump branches (such as if and switch).

[0184] Sensitive interface trigger point refers to the exact instruction location in the program code where a sensitive data API call actually occurs.

[0185] In some embodiments, during path analysis, the processor traverses the abstract syntax tree or intermediate representation to match the method name of each API call against a high-risk API library. Once a high-risk API calling this library is found, the pointer to the method body and its corresponding line number are recorded, and this is identified as the starting point of a sensitive interface. For more information on high-risk API libraries, see [link to relevant documentation]. Figure 2 And its related descriptions.

[0186] A program control flow subgraph is a data structure represented as a directed graph, used to describe the flow relationships of all possible execution paths during program code execution.

[0187] Triggering constraint equations are combinations of algebraic equations that must be satisfied for program code to reach a specific code branch.

[0188] In some embodiments, the processor traverses the program syntax tree. When it encounters an unconditional jump or conditional jump instruction, it dynamically creates the instruction as a node in memory, along with its target address or target statement, and establishes a directed connection between them to represent the jump relationship. When a sensitive interface starting point is read, the processor stops traversing the program syntax tree and generates a program control flow subgraph based on the nodes and directed connections already created in memory.

[0189] In some embodiments, the processor follows the program control flow subgraph from the entry node to the sensitive interface trigger point, extracts all branch judgment conditions on the path as symbolic variables, and concatenates them through logical AND connections to obtain the trigger constraint equation.

[0190] Constraint boundaries refer to the illegal logical range expressions defined by assertion statements.

[0191] In some embodiments, the processor reconstructs the assertion statement by applying Boolean negation logic symbols, negates the legal conditions, generates an expression to define the range of illegal logic, and determines the expression as the constraint boundary.

[0192] In some embodiments, the processor performs a logical AND operation on the constraint boundary, the program control flow subgraph, and the trigger constraint equations to obtain the constraint solving problem.

[0193] Logical solution verification refers to determining whether a constraint problem can be satisfied, that is, determining whether there exists at least one set of solutions that makes the constraint problem valid.

[0194] The verification result refers to the result obtained after logical solution verification.

[0195] The known verification results include whether a violation path exists or not.

[0196] In some embodiments, the processor converts the constraint boundaries, program control flow subgraphs, and trigger constraint equations into a logical constraint through logical AND operations, into the standard SMT-LIB format. This data is then passed to a constraint solver (e.g., Z3Solver) via an API to perform logical solution verification, determining whether at least one solution exists that makes the constraint solving problem valid. The constraint solver output can be "exists" or "does not exist," and the processor determines the verification result based on the solution result. When the constraint solver outputs "exists," a violation path is determined to exist; when the constraint solver outputs "does not exist," a violation path is determined to not exist.

[0197] A violation path refers to a code execution route that both triggers sensitive interfaces and violates constraint boundaries. For example, a code call stack sequence that bypasses the front end and directly calls the underlying GPS API without user interaction is a violation path.

[0198] The line number of the violation code refers to the specific line number in the program code corresponding to the violation path.

[0199] In some embodiments, the processor reverse-looks up the debug symbol table (such as the LineNumberTable attribute of an APK) held by the compiler based on the final instruction pointer address that triggers the sensitive interface in the violation path, and maps the pointer back to the integer line number corresponding to the program code, thereby accurately locating the line number of the violation code.

[0200] In some embodiments of this specification, by parsing the privacy protocol into assertion statements, constructing formal logical constraints by combining program control flow subgraphs and trigger constraint equations, and verifying the existence of illegal paths based on logical solutions, a "hardcore" mathematical proof of hidden illegal behavior in deep program code is achieved. Compared to vector comparison methods that rely on surface semantics, using symbolic execution and constraint solving for proof by contradiction significantly improves the accuracy and completeness of unauthorized behavior detection, and can accurately locate the specific line number of the illegal code, eliminating false alarms. Moreover, the entire process is based on formal constraint construction and automated solution execution, requiring no manual intervention, realizing a closed-loop analysis from "behavior judgment" to "code-level location," providing reliable support for mobile application permission compliance assessment.

[0201] Figure 5 This is an exemplary flowchart illustrating the determination of sensitive behaviors according to some embodiments of this specification. Figure 5 As shown, process 500 includes steps 510-560 as described below. In some embodiments, process 500 may be executed by a processor.

[0202] Step 510: Identify whether the function called in response to the sensitive access request belongs to the preset set of sensitive functions.

[0203] For more information on sensitive access requests and the accessed page, please see [link / reference]. Figure 2 And its related descriptions.

[0204] A called function refers to the specific method name or signature identifier in the program code that triggers a call from the mobile operating system.

[0205] In some embodiments, the processor can extract the string of the class name and method name being executed by reading the stack trace object to determine the function being called.

[0206] A sensitive function set refers to a collection of function calls that may involve access to sensitive data or high-risk privilege operations. For example, a sensitive function set may include API functions related to accessing location information, contacts, SMS messages, microphone, camera, and network outbound interfaces.

[0207] In some embodiments, the set of sensitive functions can be a hash table of API blacklists involving privacy data.

[0208] The function called for a sensitive access request refers to the method name or signature identifier that triggers the mobile operating system to call when a sensitive data access request is initiated.

[0209] It is known that identifying whether the called function corresponding to a sensitive access request belongs to a preset set of sensitive functions includes two cases: the called function corresponding to the sensitive access request belongs to the preset set of sensitive functions and the called function corresponding to the sensitive access request does not belong to the preset set of sensitive functions.

[0210] In some embodiments, the processor performs a precise character match on the method name string of the function called corresponding to the sensitive access request within the sensitive function set. If the match is successful, the function called corresponding to the sensitive access request is determined to belong to the sensitive function set; if the match is unsuccessful, the function called corresponding to the sensitive access request is determined not to belong to the sensitive function set.

[0211] Step 520: In response to the fact that the called function belongs to the set of sensitive functions, the semantics of the called function are matched with the page semantics of the accessed page.

[0212] Matching the semantics of a called function with the semantics of the accessed page includes two cases: the semantics of the called function match the semantics of the page, and the semantics of the called function do not match the semantics of the page.

[0213] The semantics of a function call refers to the functional intent label that the function represents at the business level, that is, the semantic description of the operation performed by the function. For example, the semantics of a location function is "to obtain user location information", and the semantics of a microphone function is "to collect audio data", etc.

[0214] In some embodiments, the processor uses the method name string of the called function as the index key to perform a hash lookup in the function-semantic mapping dictionary, retrieving the corresponding functional intent category label as the semantics of the called function. The function-semantic mapping dictionary includes multiple sets of correspondences between called functions and their corresponding functional intent labels. In some embodiments, the function-semantic mapping dictionary is preset by those skilled in the art based on experience.

[0215] Page semantics refers to the user's interaction intent expressed at the functional and business levels of the currently accessed page.

[0216] In some embodiments, the processor analyzes all text content and description fields on the page, including but not limited to control text, tags, prompts, etc.; classifies the text content into scenarios by statistical word frequency and combining it with a pre-trained classifier (such as a natural language processing classifier); and selects the tag with the highest confidence in the classification results as the page semantics.

[0217] In some embodiments, the processor determines whether the semantics of the called function match the semantics of the page by hash matching. The processor first calculates the hash values ​​of the semantics of the called function and the page semantics; then, it compares the hash value of the function semantics with the hash value of the page semantics. If the two hash values ​​are the same, it is determined that they match; otherwise, it is determined that they do not match.

[0218] Step 530: In response to the mismatch between the semantics of the called function and the semantics of the page, it is preliminarily determined that there is sensitive behavior.

[0219] For more information on sensitive behaviors, see [link to relevant information]. Figure 2 And its related descriptions.

[0220] For example, when the function call semantics are "get user location information" and the page semantics are "map navigation page", their corresponding hash values ​​are equal, and it is determined to be a match; however, when the function call semantics are "access address book" and the page semantics are "take a photo page", their hash values ​​are not equal, and it is determined to be a mismatch, thereby initially identifying potentially sensitive behaviors.

[0221] In some embodiments of this specification, by identifying whether the calling function corresponding to a sensitive access request belongs to a preset set of sensitive functions, potential sensitive calls can be quickly located, improving detection efficiency. Furthermore, by matching the semantics of the calling function with the semantics of the accessed page, and preliminarily determining the presence of sensitive behavior when they do not match, a "what you see is what you get" scenario consistency security verification mechanism is established. This mechanism, based on the semantic cross-comparison of the underlying "calling function" and the surface "page semantics," can effectively identify violations that, although authorized, do not conform to the expectations of the current scenario and thus covertly abuse permissions, significantly improving the accuracy of sensitive behavior identification and scenario awareness capabilities.

[0222] Based on the preliminary determination results, in order to further confirm the authenticity of the sensitive behavior, in some embodiments, after the preliminary determination that sensitive behavior exists, process 500 further includes steps 540-560. In some embodiments, steps 540-560 are executed by the processor.

[0223] Step 540: Obtain the click semantic sequence.

[0224] Click semantic sequence refers to a set of events on the screen that are arranged in chronological order of user touch actions and their corresponding semantic operations.

[0225] In some embodiments, the click semantic sequence includes at least one page click event and the corresponding operation semantics.

[0226] In some embodiments, the processor sets up a listener in the mobile operating system to package and store the time, location, and text button clicked for each user's screen tap into a continuously updated history pool. The processor can obtain the click semantic sequence by querying the history pool.

[0227] A page click event refers to an electronic signal event resulting from a user's finger touching a part of the screen.

[0228] The operation semantics corresponding to the page click time are the intent or function triggered by the page click event.

[0229] In some embodiments, the processor can map the coordinates of the user's click location to the layout of the page components on the current screen, determine the specific control location where the click lands through collision detection, and further extract the text information on the control to generate the corresponding operation intent, thereby determining the operation semantics of the page click event.

[0230] For example, the click semantic sequence could be: [{time:10:00:01, action: click album, operation semantic: open album}, {time: 10:00:03, action: click photo, operation semantic: select photo}, {time: 10:00:05, action: swipe, operation semantic: swipe to browse photos}, {...}].

[0231] Step 550: Retrace the operation records within the time window prior to the function call. For more information on function calls, see step 510 and its related content.

[0232] A time window refers to a defined interval within a continuous time range for analyzing, monitoring, or processing a called function. In some embodiments, the length of the time window is preset by those skilled in the art. For example, 5 seconds, 10 seconds, 30 seconds, etc.

[0233] Operation records refer to a subset of data slices that fall only within the semantic sequence of clicks within a time window.

[0234] In some embodiments, the processor queries the system log to trace back the operation records within the time window before the function was called.

[0235] It is known that finding a page click event that matches the semantics of the called function within a time window includes two cases: finding a page click event that matches the semantics of the called function and not finding a page click event that matches the semantics of the called function.

[0236] Step 560: In response to finding a page click event within the time window that matches the semantics of the called function, determine that the called function is an asynchronous and valid call; otherwise, confirm that there is sensitive behavior.

[0237] Asynchronous valid calls refer to the phenomenon where the execution time of the underlying function lags behind the user's actual click operation due to processing delays or task queuing, but the call originates from the user's real historical operations.

[0238] In some embodiments, the processor employs a loop traversal algorithm to perform synonym matching between the operation semantics of each page click event stored in the "operation record" and the semantics of the currently called function. If any operation semantics match successfully, it is determined that the current called function is a legitimate continuation of the user's historical instructions, the state machine is updated accordingly, and the operation is allowed.

[0239] For example, a user clicks "Download Photos in the Background" on page A and then quickly swipes to page B. Only then does the mobile operating system begin performing the photo read / write operation. If the semantics of the current page B are used alone, the function call would be considered mismatched with the semantics of page B. However, by traversing the user's "operation history" on page A, extracting the semantic meaning of "click to download photos," and performing a synonym match with the semantics of the underlying function call (such as "file write"), the semantic relationship between the two can be identified. This confirms that the call is a legitimate asynchronous call and allows it to proceed.

[0240] In some embodiments, if the processor finds a page click event within the time window that matches the semantics of the called function, it determines that the call is a legitimate asynchronous call and there is no sensitive behavior. Otherwise, the processor determines that there is sensitive behavior.

[0241] In some embodiments of this specification, by acquiring the click semantic sequence, the operation record within the backtracking time window, and determining the legitimate asynchronous call, it is possible to tolerate the spatiotemporal misalignment caused by the asynchronous execution of mobile applications, network latency, or users' rapid page switching. This effectively reduces the false alarm rate under multi-threaded and asynchronous architectures, accurately distinguishes between genuine malicious background theft and legitimate asynchronous tasks, and improves the accuracy of abnormal behavior control.

[0242] It should be noted that the above descriptions of processes 200 and 500 are for illustrative purposes only and do not limit the scope of this specification. Those skilled in the art can make various modifications and changes to processes 200 and 500 under the guidance of this specification. However, these modifications and changes remain within the scope of this specification.

[0243] The basic concepts have been described above. Obviously, for those skilled in the art, the detailed disclosure above is merely illustrative and does not constitute a limitation of this specification. Although not explicitly stated herein, those skilled in the art may make various modifications, improvements, and corrections to this specification. Such modifications, improvements, and corrections are suggested in this specification and therefore remain within the spirit and scope of the exemplary embodiments described herein.

[0244] Furthermore, this specification uses specific terms to describe embodiments thereof. For example, "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Moreover, certain features, structures, or characteristics in one or more embodiments of this specification can be appropriately combined.

[0245] Furthermore, unless expressly stated in the claims, the order of processing elements and sequences, the use of numbers and letters, or other names described in this specification are not intended to limit the order of the processes and methods described herein. Although various examples have been discussed in the foregoing disclosure of some embodiments of the invention that are currently considered useful, it should be understood that such details are for illustrative purposes only, and the appended claims are not limited to the disclosed embodiments; rather, the claims are intended to cover all modifications and equivalent combinations that conform to the spirit and scope of the embodiments described herein. For example, while the system components described above can be implemented using hardware devices, they can also be implemented solely using software solutions, such as installing the described system on existing servers or mobile devices.

[0246] Similarly, it should be noted that, in order to simplify the description disclosed herein and thus aid in the understanding of one or more embodiments of the invention, the foregoing description of embodiments in this specification may sometimes combine multiple features into a single embodiment, drawing, or description thereof. However, this method of disclosure does not imply that the subject matter of this specification requires more features than those mentioned in the claims. In fact, the embodiments contain fewer features than all the features of a single embodiment disclosed above.

[0247] In some embodiments, numbers describing the quantity of components and attributes are used. It should be understood that such numbers used in the description of embodiments are modified in some examples with the terms "approximately," "approximately," or "generally." Unless otherwise stated, "approximately," "approximately," or "generally" indicates that the numbers are allowed to vary by ±20%. Accordingly, in some embodiments, the numerical parameters used in the specification and claims are approximate values, which may be changed depending on the characteristics required by individual embodiments. In some embodiments, numerical parameters should take into account specified significant digits and employ a general method of digit reservation. Although the numerical ranges and parameters used to confirm their breadth of range in some embodiments of this specification are approximate values, in specific embodiments, such values ​​are set as precisely as feasible.

[0248] For each patent, patent application, patent application publication, and other material such as articles, books, specifications, publications, and documents referenced in this specification, the entire contents of which are incorporated herein by reference. This excludes historical application documents that are inconsistent with or conflict with the content of this specification, as well as documents that limit the broadest scope of the claims in this specification (currently or subsequently appended to this specification). It should be noted that in the event of any inconsistency or conflict between the descriptions, definitions, and / or terminology used in the supplementary materials to this specification and the content of this specification, the descriptions, definitions, and / or terminology used in this specification shall prevail.

[0249] Finally, it should be understood that the embodiments described in this specification are merely illustrative of the principles of the embodiments described herein. Other variations may also fall within the scope of this specification. Therefore, alternative configurations of the embodiments described herein are intended to be illustrative rather than limiting, and should be considered consistent with the teachings of this specification. Accordingly, the embodiments described herein are not limited to those explicitly introduced and described herein.

Claims

1. An automated detection method for mobile application data security risks, characterized in that, The method includes: Based on the outgoing data packets of the mobile application, obtain the access data of the mobile application; Based on static information and the access data, the abnormal behavior of the mobile application is identified; Based on the aforementioned abnormal behavior, the abnormal application is identified; Based on the access data, the abnormal behavior, and the abnormal application, access control is performed.

2. The method according to claim 1, characterized in that, The access data includes target network parameters; The permission control based on the access data, the abnormal behavior, and the abnormal application includes: Statistically analyze the frequency characteristics of the abnormal behavior within a preset time window; Based on the frequency characteristics, a first control instruction with a corresponding control strength value is generated, and the first control instruction is configured to restrict the abnormal application from reading target data. The degree of discretization of the target network parameters within the preset time window is statistically analyzed. Based on the degree of discretization, the interception parameters are determined; Control the associated gateway device to intercept the target data based on the interception parameters.

3. The method according to claim 1, characterized in that, The static information includes a privacy agreement; the abnormal behavior includes unauthorized behavior. The acquisition of the mobile application's access data includes: intercepting sensitive access requests initiated by the mobile application; The step of identifying abnormal behavior of the mobile application based on static information and access data includes: determining whether the mobile application exhibits the over-permission behavior.

4. The method according to claim 3, characterized in that, Determining whether the mobile application exhibits the excessive permission behavior includes: Based on the privacy protocol, a first feature vector is determined; Based on the actual invocation permissions corresponding to the sensitive access request, a second feature vector is determined; Calculate the similarity between the first feature vector and the second feature vector; In response to the similarity being less than a similarity threshold, it is determined that the unauthorized behavior exists.

5. The method according to claim 3, characterized in that, The step of determining whether the mobile application exhibits the excessive permission behavior also includes: The privacy agreement is parsed into corresponding assertion statements; Path analysis is performed on the program code of the mobile application to extract the program control flow subgraph and trigger constraint equations leading to the sensitive interface trigger points; The assertion statement is inverted and used as the constraint boundary. After performing a logical AND operation with the program control flow subgraph and the trigger constraint equation, the logical solution is verified to obtain the verification result. In response to the verification result indicating the existence of an illegal path, the illegal code line number is extracted, and based on the illegal code line number, it is determined that the unauthorized behavior exists.

6. The method according to claim 1, characterized in that, The method of performing access control based on the access data, the abnormal behavior, and the abnormal application also includes: Determine whether the program interface that triggered the abnormal behavior reads preset sensitive information; In response to the program interface reading the preset sensitive information, the first control command is intercepted; Based on the program interface, a second control instruction is generated and sent. The second control instruction is configured to return simulation data by reading the preset sensitive information.

7. An automated detection system for mobile application data security risks, characterized in that, The system includes: The acquisition module is configured to: acquire access data of the mobile application based on the outgoing data packets of the mobile application; The recognition module is configured as follows: Based on static information and the access data, the abnormal behavior of the mobile application is identified; Based on the aforementioned abnormal behavior, the abnormal application is identified; The control module is configured to perform permission control based on the access data, the abnormal behavior, and the abnormal application.

8. The system according to claim 7, characterized in that, The access data includes target network parameters; the control module is further configured to: Statistically analyze the frequency characteristics of the abnormal behavior within a preset time window; Based on the frequency characteristics, a first control instruction with a corresponding control strength value is generated, and the first control instruction is configured to restrict the abnormal application from reading target data. The degree of discretization of the target network parameters within the preset time window is statistically analyzed. Based on the degree of discretization, the interception parameters are determined; Control the associated gateway device to intercept the target data based on the interception parameters.

9. The system according to claim 7, characterized in that, The static information includes a privacy agreement; the abnormal behavior includes unauthorized behavior. The acquisition module is further configured to: intercept sensitive access requests initiated by the mobile application; The identification module is further configured to: determine whether the mobile application exhibits the over-permission behavior.

10. The system according to claim 7, characterized in that, The control module is further configured as follows: Determine whether the program interface that triggered the abnormal behavior reads preset sensitive information; In response to the program interface reading the preset sensitive information, the first control command is intercepted; Based on the program interface, a second control instruction is generated and sent. The second control instruction is configured to return simulation data by reading the preset sensitive information.

Images