Mobile application malicious behavior detection method and system based on scene context driving

Abstract

The invention relates to the field of mobile application security, and discloses a scene context driven mobile application malicious behavior detection method and system, and the method comprises the following steps: collecting multi-source information during application operation, and carrying out scene recognition; capturing sensitive behaviors in real time and performing standardized cleaning treatment; semantic information of the manifest permission declaration and the privacy policy text is extracted, a declaration triple is constructed, and declaration consistency judgment is carried out; constructing an application behavior graph, and calculating a plurality of risk indexes of nodes in the graph to obtain malicious scores; according to the method, a running scene is used as a core analysis dimension, a dynamic behavior sequence, a sensitive API call chain, application declaration semantics and a cross-source consistency comparison mechanism are combined, and the dynamic behavior sequence, the sensitive API call chain, the dynamic behavior sequence, the sensitive API call chain, the dynamic behavior sequence and the cross-source consistency comparison mechanism are combined, so that the dynamic behavior sequence and the sensitive API call chain are combined, and the high-risk nodes and the high-risk paths with malicious scores exceeding a threshold value are screened. And accurate identification of malicious operation of the mobile application is realized.

Description

Technical Field

[0001] This invention belongs to the field of mobile application security, specifically relating to a method and system for detecting malicious behavior in mobile applications based on scenario context. Background Technology

[0002] With the widespread adoption of mobile internet and smart terminals, the number and complexity of mobile applications have exploded. The behaviors generated by these applications during operation are becoming increasingly diverse, including foreground interaction, background updates, data communication, permission requests, and system event responses. Simultaneously, malware, in order to evade detection, is increasingly employing various methods such as scene-aware evasion, permission abuse, covert communication, and dynamic loading, posing a severe challenge to mobile terminal security. Against this backdrop, accurately identifying the behavioral intent of applications in different operating scenarios and promptly detecting potential malicious operations has become a key challenge in the field of mobile application security.

[0003] Currently, mainstream mobile malware detection technologies are mainly divided into two categories: static analysis and dynamic behavior analysis. Static analysis techniques typically rely on bytecode feature matching, string rules, and permission pattern analysis. Their technical characteristics include parsing the APK package structure, analyzing manifest permission entries, and extracting sensitive API call sequences. However, with the widespread use of obfuscation techniques, reflection calls, dynamic code loading, and hardening techniques, traditional static analysis struggles to fully recover code logic and has significant limitations in real-world attack scenarios.

[0004] Dynamic behavior analysis technology detects potential malicious operations by running applications in sandboxes or on devices and monitoring their API call behavior, system event responses, data access, and network communication in real time. Typical methods include recording call sequences, tracing execution paths, and analyzing sensitive behavior patterns. However, this type of technology generally lacks the ability to model the "context in which the behavior occurs," making it impossible to determine whether a behavior is normal within the current context. For example, calling a sensitive API when the user explicitly interacts with the interface is reasonable, but the same behavior occurring in the background or in a non-interactive scenario may indicate malicious intent. Existing dynamic detection systems only focus on the behavior itself, ignoring the semantic context behind it, thus making it difficult to effectively identify covert malicious behavior.

[0005] Furthermore, recent research has shown that discrepancies frequently exist between mobile applications' stated information (such as permission statements, feature descriptions, and privacy policies) and their actual operation. Many applications, even those that prohibit access to sensitive data in their privacy policies, may still frequently collect location, device information, or user data in the background. However, traditional detection technologies lack cross-source information comparison capabilities and do not have mechanisms for automatically determining "statement-behavior inconsistencies," making it difficult to detect violations in a timely manner.

[0006] In summary, existing technologies generally suffer from the following problems:

[0007] Lacking the ability to process contextual semantics, it cannot determine whether the behavior conforms to the expectations of the scenario;

[0008] The system cannot automatically compare the consistency between statements and actual behavior, making it difficult to detect violations.

[0009] Insufficient detection capabilities when faced with malicious strategies such as dynamic loading and covert triggering;

[0010] Without interpretive analysis of behavioral intent, auditing systems struggle to establish reliable chains of evidence. Summary of the Invention

[0011] To address the technical problems of existing technologies, such as lack of scene context semantic processing capabilities, inability to automatically compare the consistency between claims and actual behavior, insufficient detection capabilities against malicious strategies, and lack of interpretive analysis of behavioral intent, this invention provides a mobile application malicious behavior detection method and system based on scene context driving, comprising the following steps:

[0012] Step 1: Collect multi-source information during application runtime, identify application runtime scenarios, and obtain scenario sequences;

[0013] Step 2: Capture sensitive behaviors in real time through dynamic behavior capture. The sensitive behaviors are accompanied by scene tags, timestamps and call parameters, and are processed into behavior sequences through standardized cleaning.

[0014] Step 3: Extract semantic information from the manifest permission declaration and privacy policy text through declaration semantic parsing, construct declaration triples, and perform declaration consistency determination;

[0015] Step 4: Based on the above scenario sequence, behavior sequence and declaration triples, perform behavior graph modeling, construct application behavior graph, calculate multiple risk indicators of nodes in the application behavior graph, perform weighted summation to obtain the malicious score;

[0016] Step 5: Filter high-risk nodes and paths with malicious scores exceeding the threshold, generate evidence nodes based on the time of occurrence, the scene, sensitive API calls, data flow information, and declaration conflicts. The evidence nodes are linked together in the execution order to form a complete evidence chain, and exported as a visual chart and text report.

[0017] Furthermore, step 1 specifically involves: receiving multi-source information during application runtime, including lifecycle events, UI structure changes, user interaction records, and system broadcast links; constructing a set of events to be identified; using a lightweight HEAD request to obtain response header information; generating a preliminary scene sequence and tags based on event type and triggering order, including foreground interaction scenarios, background silent update scenarios, sensitive permission request scenarios, data upload scenarios, and message response scenarios; cleaning the preliminary scene sequence, removing invalid events, eliminating redundant preliminary scene tags, and correcting rule conflicts; and standardizing the preliminary scene sequence to obtain a scene sequence that supports subsequent operations.

[0018] Furthermore, step 2 specifically involves: capturing sensitive behaviors in real time through a Hook framework, dynamic instrumentation, or sandbox mechanism, including sensitive API calls, permission usage actions, file reading behaviors, network access requests, and cross-component communication; constructing a set of behaviors to be analyzed; mapping each behavior to a structured behavior event based on its occurrence time and corresponding scene tag; and standardizing and cleaning the structured behavior events by removing invalid calls, merging repeated behaviors within a short period, restoring the true time sequence of behaviors, and unifying field formats to obtain a behavior sequence that supports subsequent operations.

[0019] Furthermore, step 3 specifically involves: statically parsing the manifest file to identify the permission list and registration information of sensitive components; and using natural language processing methods to perform syntactic analysis and semantic extraction on the terms in the privacy policy text to obtain semantic information including the purpose of the permission, the data processing method, and the scope of responsibility, and constructing it into structured declaration triples. Each triple includes data type, purpose, and scope of responsibility. Based on the behavior sequence, each behavior event is mapped to a behavior triple, and the semantic deviation between the declaration triple and the behavior triple is calculated, i.e., the declaration deviation degree. When the semantic deviation exceeds a set threshold, the behavior event is marked as a declaration inconsistency behavior and written into the abnormal event set as the input part for subsequent application of behavior graph reasoning.

[0020] Furthermore, the calculation of semantic bias specifically involves: converting the declaration triples and behavior triples into standardized semantic text, encoding the semantic text of the declaration triples, and obtaining a set of declaration semantic vectors.

[0021] ,

[0022] in, Represents a semantic vector model. To declare the semantic text representing the data type in the triple, To declare the semantic text in the triple that indicates the purpose of the data, To declare the semantic text in the triple that represents the scope of responsibility;

[0023] Encoding the semantic text of the behavior triples yields a set of behavior semantic vectors:

[0024] ,

[0025] in, The semantic text representing the data type in the behavior triple. The semantic text in the behavior triple that represents the purpose of the data. The semantic text representing the scope of responsibility in the behavior triple;

[0026] Based on the distance or similarity relationship between semantic vectors, the semantic similarity between the declaration triples and the behavior triples is calculated across each field dimension. Cosine similarity is used as the measure of semantic similarity, and the results are as follows:

[0027] ;

[0028] ;

[0029] ;

[0030] in, , , These represent semantic similarity in terms of data type, data purpose, and scope of responsibility, respectively.

[0031] The semantic similarity of each field dimension is weighted and fused to obtain the overall semantic consistency score between the declaration and the behavior:

[0032] ,

[0033] in, To declare a triple, For behavior triples, , , Let be the weight coefficient of the corresponding field, and satisfy . ;

[0034] Based on this, the semantic deviation between declaration and behavior is defined as:

[0035] ;

[0036] When the same application corresponds to multiple declaration triples, for each row triple, its semantic consistency score is calculated among all declaration triples, and the maximum value is selected as the overall semantic consistency score for that row:

[0037] ,

[0038] And calculate the corresponding semantic bias accordingly:

[0039] .

[0040] Furthermore, step 4 specifically involves: performing behavior graph modeling based on the scenario sequence, behavior sequence, and declaration triples to construct an application behavior graph; calculating multiple risk indicators for each node in the application behavior graph, including degree centrality, betweenness centrality, behavior deviation, declaration deviation, and sensitive API operation weights; weighting and summing the risk indicators according to preset weights to obtain a malicious score; and using the malicious score result as the basis for ranking node risks.

[0041] Furthermore, the calculation of multiple risk indicators specifically involves:

[0042] Behavior deviation calculation: Based on the scene sequence, a set of expected behaviors is pre-determined for each scene. When a node is a behavior / API node, the behavior corresponding to that node is represented as... And calculate its behavioral deviation relative to the current scene:

[0043] ,

[0044] in, For the set of expected behaviors, This represents a measure of behavioral similarity, achieved through category matching, rule matching, or semantic similarity.

[0045] Betweenness centrality calculation: Based on the topology calculation of the behavioral graph, the betweenness centrality of a node is used to measure its bridging role in the behavioral chain. The calculation formula is as follows:

[0046] ,

[0047] in, Indicates from node To the node The number of shortest paths, Indicates passing through nodes The number of shortest paths;

[0048] Sensitive API operation weight calculation: A set of sensitive APIs and a set of sensitive data types are preset. When a node is associated with a sensitive API or sensitive data, a sensitive API operation weight is assigned to it.

[0049] ,

[0050] in, This represents the sensitivity level mapping value. If a node is involved in both sensitive data access and external transmission, its sensitive API operation weight is increased.

[0051] ,

[0052] in, This is an additional boost to the multiplier;

[0053] Degree centrality calculation: Based on the application behavioral graph topology, the degree centrality of a node is calculated, which is defined as the sum of the node's in-degree and out-degree.

[0054] ,

[0055] in, Indicates pointing to a node The number of edges, Indicates from node The number of edges emitted.

[0056] Furthermore, step 5 specifically involves: selecting behavioral nodes whose malicious scores exceed a threshold from the set of high-risk nodes, recovering the complete temporal chain generated by the behavior based on its associated behavioral path, converting the behavioral nodes into evidence nodes, recording their information, including timestamps, the scene to which they belong, the API called, the data types involved, the content of the declaration conflict, and the malicious score, connecting multiple evidence nodes in chronological order to form an evidence chain, and outputting the evidence chain and malicious behavior report, including a behavior path visualization diagram, a declaration conflict explanation, and a malicious score detail.

[0057] A scenario-context-driven mobile application malicious behavior detection system, used to implement any of the methods described above, includes the following modules:

[0058] Scene recognition and behavior acquisition module: used to collect event sequences, identify application running scenarios, capture dynamic behaviors, and standardize behavior processing;

[0059] Declaration Consistency and Behavior Graph Analysis Module: Used for declaration semantic parsing and triple modeling, comparing declarations with behaviors, constructing application behavior graphs, and calculating multi-dimensional maliciousness scores for nodes in the behavior graph;

[0060] Explainable Evidence Chain Generation Module: Filters high-risk nodes, reconstructs the temporal chain of their related behaviors, generates a structured evidence chain composed of evidence nodes, and outputs visual charts and text reports.

[0061] Beneficial effects:

[0062] This invention accurately identifies malicious operations that are inconsistent with the context through scene awareness and context analysis; it comprehensively detects abuse of permissions and privacy violations by combining declaration parsing and behavior comparison; it improves the accuracy of malicious intent identification based on dynamic behavior graph modeling and multi-source fusion analysis; and it supports security auditing and regulatory requirements by providing an interpretable chain of evidence for malicious behavior. Attached Figure Description

[0063] Figure 1 This is a flowchart of a scenario-context-driven mobile application malicious behavior detection method.

[0064] Figure 2 This is a model diagram of a mobile application malicious behavior detection system based on scene context. Detailed Implementation

[0065] The specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0066] The technical terms involved in this invention are:

[0067] 1. Application runtime scenario identification

[0068] Application runtime scenario identification is the core foundation of this invention, used to determine the runtime context state of an application at different points in time. The runtime scenario of a mobile application is typically determined by multiple dimensions of signals, including lifecycle events (such as the start, pause, and destruction of Activities and Services), user interface structure (UI hierarchy, interactive components), user input behaviors (clicks, swipes, input events), system broadcast triggers, and Intent navigation paths. By extracting, filtering, and modeling these event sequences, scenario identifiers are generated for the application during runtime, including but not limited to foreground interaction scenarios, background silent update scenarios, sensitive permission request scenarios, data upload scenarios, and message response scenarios. Scenario identification not only reflects the real-time interaction state of the application but also constructs the semantic context of the behavior, providing a semantic basis for subsequent behavior consistency analysis and malicious behavior determination. This invention transforms complex runtime states into structured scenario tags through scenario identification, thereby ensuring the integrity and accuracy of the environmental context during behavior analysis.

[0069] 2. Dynamic behavior capture

[0070] Dynamic behavior capture records the actual operations of an application during runtime, implemented through a Hook framework, dynamic instrumentation technology, or a runtime sandbox mechanism. This invention monitors key behaviors in real time during application runtime, including sensitive API calls, permission usage records, network access requests, file operations, data reading and reporting behaviors, system calls, and cross-component communication. Particularly for sensitive APIs involving user privacy and device resources, such as location services, device identifier reading, camera and microphone access, contact list reading, SMS sending, and network data uploading, this invention focuses on capturing relevant calls and their parameters, trigger sources, call times, and execution scenarios. All behaviors are standardized into a unified format, accompanied by precise timestamps and scenario tags, thus forming a high-quality behavior dataset that can be used for comparison and analysis. This process provides crucial underlying support for detecting inconsistent behaviors in different scenarios and identifying malicious intent.

[0071] 3. Semantic parsing and triple construction of declarations

[0072] Semantic declaration parsing technology is used to extract permission statements, data usage purposes, and scope of responsibility from application manifest files and privacy policy texts. This invention identifies permission lists and registration information of sensitive components (such as Services and Receivers) through static parsing of the manifest file, and utilizes Natural Language Processing (NLP) methods to perform syntactic analysis and semantic extraction on the terms in the privacy policy. Finally, the declaration content is uniformly constructed into structured triples (data type, purpose, scope of responsibility), such as (location, personalized recommendation, local processing). These triples clearly express the data processing methods claimed by the application in the document, providing a standardized reference for subsequent semantic comparison and consistency verification. The declaration parsing process ensures an automated, item-by-item comparison between "what the application claims to do" and "what the application actually does."

[0073] 4. Behavior diagram modeling

[0074] Network topology, described by a graph G(V, E) depicting the relationship between nodes V and connections E, is an important tool for studying computer networks and distributed systems. Degree centrality in graph theory measures the number of direct connections to a node, reflecting its local importance; betweenness centrality measures a node's role as a bridge, reflecting its global influence. Furthermore, dynamic topology focuses on the addition, loss, and migration of nodes, which significantly impact network performance and resource distribution. In dynamic resource scale estimation, network topology, combined with attributes such as latency and bandwidth, is modeled using weighted graphs, providing a mathematical foundation for multi-dimensional index quantification and comprehensive scoring calculations, which is a crucial theoretical support for the analysis in this invention.

[0075] 5. Determination of behavioral deviation from statement consistency

[0076] Behavioral deviation is used to measure whether a specific behavior violates the normal expected set of behaviors in its context. This invention maintains a reference set of allowed behaviors for each type of scenario (e.g., foreground interaction, background operation, permission request scenarios, etc.). Deviation is calculated by the distance between a behavioral feature and the allowed set for the scenario, thereby determining whether the behavior is inconsistent with the scenario. Simultaneously, declaration consistency judgment is used to assess whether the application's runtime behavior is consistent with its manifest declaration and privacy policy description. By comparing the semantic deviation between declaration triples and behavioral triples, deviation is calculated to identify undeclared data access, privacy violations, and conflicts between the application's self-declaration and actual operation. These two types of deviation, combined with the behavioral importance index in behavioral graph modeling, constitute a comprehensive malicious score, used to identify malicious behavior and provide interpretable analysis results.

[0077] This invention proposes a scenario-context-driven method for detecting malicious behavior in mobile applications. By using scenario semantic inference, behavior consistency comparison, and multi-source behavior graph modeling, it achieves high-precision identification of malicious software, solving the core problem that existing detection technologies cannot determine whether the behavior is consistent with the current scenario, thereby improving the accuracy, robustness, and interpretability of malicious behavior detection.

[0078] like Figure 1 As shown, the mobile application malicious behavior detection method based on scene context driving of the present invention includes the following steps:

[0079] Step 1: Scene Recognition and Running Status Analysis

[0080] This method requires scene identification and standardization processing of a set of raw event sequences generated during application operation. To ensure that the scene information is complete, reliable, and accurately reflects the application's operating status, the following steps are performed sequentially after receiving the event sequence:

[0081] 1.1 Receive lifecycle events, UI structure changes, user interaction records, and system broadcast links generated during application runtime, construct a set of events to be identified, and ensure coverage of key state changes during application operation. Employ lightweight HEAD requests to obtain response header information, reducing network resource consumption and supporting both client-side and server-side operation.

[0082] 1.2. Based on the event type and triggering order, use the scenario inference model to generate preliminary scenario labels, such as front-end interaction scenarios, background silent operation scenarios, and sensitive permission request scenarios.

[0083] 1.3 Clean the initial scene sequence by removing invalid events, eliminating redundant scene labels, and correcting rule conflicts to ensure the integrity and continuity of the scene sequence.

[0084] 1.4. Call the CleanScene function to standardize the scene sequence, obtaining a noise-reduced, non-repeating, and structurally stable scene sequence. The pseudocode for the CleanScene function is as follows:

[0085] function CleanScene(events,status,count)

[0086] for i=0 to count−1 do

[0087] if status[i] == valid and events[i] not in cleaned then

[0088] cleaned[cleaned_count++] = events[i]

[0089] end if

[0090] end for

[0091] return cleaned

[0092] This function is primarily used to clean and standardize scene sequences. By traversing the event sequence and checking the validity of events, the function identifies and retains truly valid scene labels while removing invalid, duplicate, or noisy events, thus ensuring the integrity and consistency of the scene data. Ultimately, the function returns high-quality scene sequences that can be used for behavioral analysis, providing a reliable foundation for subsequent processing.

[0093] 1.5 Store the cleaned scene sequence to provide semantic context support for subsequent behavior collection and declaration consistency determination.

[0094] Step 2: Behavior Collection and Standardization

[0095] This method requires capturing, formatting, and merging sensitive behaviors generated during mobile application runtime. To ensure the integrity, efficiency, and direct usability of the behavioral data by subsequent analysis modules, the following steps are performed sequentially:

[0096] 2.1 Capture sensitive API calls, permission usage actions, file reading behavior, network access requests, cross-component communication (such as Intent, Binder) in real time, and build a set of behaviors to be analyzed.

[0097] 2.2 Based on the time of occurrence of the behavior and its corresponding scene tag, map each behavior to a structured behavior event, including timestamp, scene tag, API name, parameter summary and data type information.

[0098] 2.3 Standardize and clean the behavioral event sequence, including removing invalid calls, merging repeated behaviors within a short period of time, restoring the true time sequence of behaviors, and unifying the field format to standardize the behavioral sequence.

[0099] 2.4 Store the standardized behavior sequence for subsequent declaration consistency determination and behavior graph modeling process.

[0100] Step 3: Declaring Consistency and Constructing Triples

[0101] This method requires consistency analysis between the application's declared content and its actual runtime behavior. The declared content includes manifest permission statements, component usage descriptions, and privacy policy terms, etc. After receiving the relevant data, the following steps are executed sequentially:

[0102] 3.1. Parse the manifest file to extract permission declarations, sensitive component registrations, and their usage descriptions. Also, parse the privacy policy text and construct declaration triples from information such as data processing purposes and scope of use.

[0103] ,

[0104] in, Represents data type, Indicate the purpose of the data. This indicates the scope of responsibility for data processing or the constraints on its use.

[0105] 3.2 Simultaneously, the runtime behavior of the application is monitored and analyzed, mapping the data access, processing, and transmission behaviors involved into behavior triples:

[0106] ,

[0107] in, , , These respectively indicate the data types, data uses, and scope of responsibility for data processing involved in the actual operation.

[0108] 3.3 To facilitate semantic computation, the declaration triples and behavior triples are converted into standardized semantic text. The semantic text of the declaration triples is then encoded to obtain a set of declaration semantic vectors:

[0109] ,

[0110] in, This represents a semantic vector model, used to characterize the representation of different texts in a semantic space. To declare the semantic text representing the data type in the triple, To declare the semantic text in the triple that indicates the purpose of the data, To declare the semantic text in the triple that represents the scope of responsibility;

[0111] Encoding the semantic text of the behavior triples yields a set of behavior semantic vectors:

[0112] ,

[0113] in, The semantic text representing the data type in the behavior triple. The semantic text in the behavior triple that represents the purpose of the data. The semantic text representing the scope of responsibility in the behavior triple.

[0114] 3.4. Based on the distance or similarity relationship between semantic vectors, calculate the semantic similarity between the declaration triples and the behavior triples across each field dimension. Cosine similarity is used as the semantic similarity metric. The calculated results are as follows:

[0115] ;

[0116] ;

[0117] ;

[0118] in, , , These represent semantic similarity in terms of data type, data purpose, and scope of responsibility, respectively.

[0119] 3.5. Weighted fusion of semantic similarity across all fields yields the overall semantic consistency score between declaration and behavior:

[0120] ,

[0121] in, , , Let be the weight coefficient of the corresponding field, and satisfy . ;

[0122] Based on this, the semantic deviation between declaration and behavior is defined as:

[0123] ,

[0124] Semantic bias Used to quantify the degree of semantic inconsistency between the declared behavior and the actual runtime behavior of an application. The larger the value, the greater the degree of deviation.

[0125] 3.6 When the same application corresponds to multiple declaration triples, for each row triple, calculate its semantic consistency score among all declaration triples, and select the maximum value as the overall semantic consistency score for that row:

[0126] ,

[0127] And calculate the corresponding semantic bias accordingly:

[0128] .

[0129] 3.7. Compare the semantic deviation with a preset threshold. When the semantic deviation exceeds the preset threshold, mark the behavior event as an inconsistent behavior and write it into the abnormal event set as the input part of subsequent malicious graph reasoning.

[0130] Step 4: Behavioral Graph Reasoning and Malicious Scoring

[0131] This invention requires constructing a behavior graph from standardized behavior sequences, performing risk scoring on the nodes of this graph, and identifying potential malicious behavior chains. The process is as follows:

[0132] 4.1 Unify the modeling of scene nodes, behavior nodes, data nodes and declaration nodes to construct an application behavior graph, where nodes represent behavior or scene states and edges represent call dependencies, triggering relationships or data flows.

[0133] 4.2 Calculate multiple risk indicators for each node in the behavioral graph, including behavioral deviation, claim deviation, node betweenness centrality, and sensitive API operation weights:

[0134] Behavior deviation calculation: Based on the scene sequence, a set of expected behaviors is pre-determined for each scene. When a node is a behavior / API node, the behavior corresponding to that node is represented as... And calculate its behavioral deviation relative to the current scene:

[0135] ,

[0136] in, For the set of expected behaviors, This represents a measure of behavioral similarity, achieved through category matching, rule matching, or semantic similarity.

[0137] Betweenness centrality calculation: Based on the topology calculation of the behavioral graph, the betweenness centrality of a node is used to measure its bridging role in the behavioral chain. The calculation formula is as follows:

[0138] ,

[0139] in, Indicates from node To the node The number of shortest paths, Indicates passing through nodes The number of shortest paths;

[0140] Sensitive API operation weight calculation: A set of sensitive APIs and a set of sensitive data types are preset. When a node is associated with a sensitive API or sensitive data, a sensitive API operation weight is assigned to it.

[0141] ,

[0142] in, This represents the sensitivity level mapping value. If a node is involved in both sensitive data access and external transmission, its sensitive API operation weight is increased.

[0143] ,

[0144] in, This is an additional boost to the multiplier;

[0145] Degree centrality calculation: Based on the application behavioral graph topology, the degree centrality of a node is calculated, which is defined as the sum of the node's in-degree and out-degree.

[0146] ,

[0147] in, Indicates pointing to a node The number of edges, Indicates from node The larger the degree centrality value of the number of edges emitted, the more other behavioral nodes the node is directly associated with, and the higher its activity level and potential risk impact in the local behavioral structure.

[0148] 4.3 Call the ComputeScore function to perform a weighted summation of multiple metrics according to preset weights to obtain the malicious score of the node. The pseudocode of the ComputeScore function is as follows:

[0149] function ComputeScore(weights, , , , )

[0150] score = Sum(weights * [ , , , ])

[0151] return score

[0152] in, For behavioral deviation, To declare deviation, For degree centrality, For betweenness centrality, This function assigns weights to sensitive API operations, with `weights` being the weight parameter indicating the importance of each indicator. It combines multiple risk indicators into a comprehensive score using a weighted calculation method to measure the maliciousness of a node. The score is then used as the basis for ranking node risk, providing a quantitative standard for subsequent abnormal chain identification.

[0153] 4.4. Based on the malicious scoring results, high-risk nodes are screened, and path subgraphs that may constitute malicious behavior are extracted to prepare for the next stage of evidence chain generation.

[0154] 5. Generation of an interpretable chain of evidence for malicious behavior

[0155] After identifying malicious nodes, the process moves to the evidence chain generation stage, which is used to construct a complete and traceable evidence chain of malicious behavior. The steps are as follows:

[0156] 5.1 Select nodes whose malicious scores exceed the threshold from the set of high-risk nodes, and restore the complete temporal chain generated by the behavior based on the associated behavioral paths.

[0157] 5.2 Convert behavior nodes into evidence nodes, recording information such as timestamps, scenarios, API calls, data types involved, content of content conflicts, and malicious scoring.

[0158] 5.3 Call the BuildEvidenceChain function to chain multiple evidence nodes together in chronological order. The pseudocode for BuildEvidenceChain is as follows:

[0159] function BuildEvidenceChain(paths,decls)

[0160] for path in paths:

[0161] chain=[]

[0162] for node in path:

[0163] evidence = extract(node,decls)

[0164] chain.append(evidence)

[0165] return chains

[0166] This function traverses high-risk paths, converting each behavioral node into a structured unit of evidence, and constructs a complete chain of evidence in the order in which the behaviors occur. The returned set of evidence contains key data that can be used for auditing and evidence collection, and is highly interpretable and logically clear.

[0167] 5.4 Output the chain of evidence and malicious behavior reports, including a visualization of the behavior path, explanations of conflicting statements, and details of malicious scoring, to provide traceable evidence for audit analysis and security supervision.

[0168] To implement the aforementioned method, this invention constructs a mobile application malicious behavior detection system based on scenario context. This system centers on scenario recognition, uses behavior consistency analysis and malicious intent inference as its main framework, and combines application declaration parsing and behavior graph modeling to form an interpretable, high-precision, and reproducible malware detection system. The system comprises a scenario recognition and behavior acquisition module, a declaration consistency and behavior graph analysis module, and an interpretability evidence chain generation module. It can continuously monitor the behavior of applications in their real-world operating environment and provide timely judgments and explanations when violations or malicious operations occur.

[0169] like Figure 2 As shown, the mobile application malicious behavior detection system based on scene context driving of the present invention includes the following structure:

[0170] Scene Recognition and Behavior Acquisition Module: This module is used for event sequence acquisition, application runtime scene identification, and dynamic behavior capture. The system quickly infers the current runtime scene of the application by collecting multi-source information such as application runtime lifecycle events, UI structure, user interactions, system broadcast triggers, and Intent routing. The system identifies various scene types, including foreground interactions, background updates, sensitive permission requests, and data uploads, through event fusion and scene classification models. The system captures sensitive behaviors in real time through a Hook framework, dynamic instrumentation, or sandbox mechanisms, including sensitive API calls, permission usage, data access, network communication, and cross-component operations. Captured behavior records are accompanied by scene tags, timestamps, and call parameters, and are processed through standardization, deduplication, and time-sequence restoration to form a unified behavior sequence.

[0171] The Declaration Consistency and Behavior Graph Analysis module identifies inconsistencies between application declarations and actual behavior, and constructs a behavior graph. The system parses the manifest permission declaration and privacy policy text, extracting semantic information such as permission purpose, data processing method, and scope of responsibility, and constructs declaration triples (data type, purpose, scope of responsibility). Subsequently, the system converts runtime behavior into behavior triples and calculates the declaration deviation using a semantic vector model. Based on scenario sequences, behavior sequences, and declaration triples, the system constructs an application behavior graph. Nodes in this behavior graph include scenario nodes, API nodes, data nodes, and declaration nodes; edges represent call dependencies, data flow paths, or trigger links. The system calculates the degree centrality, betweenness centrality, behavior deviation, declaration deviation, and sensitive operation weights of nodes, performing a comprehensive analysis of the behavior chain to generate a malicious score, identifying cross-scenario, cross-event chain, and combined malicious behaviors.

[0172] The Explainable Evidence Chain Generation Module is used to structure detected risky behaviors into a traceable, verifiable, and auditable evidence chain. The system first filters high-risk nodes and paths with malicious scores exceeding a threshold. Then, it generates evidence nodes based on the behavior's occurrence time, context, sensitive API calls, data flow information, and claim conflicts. These evidence nodes are chained together in execution order to form a complete evidence chain, which is then exported as visual charts and text reports for manual review, compliance auditing, and security monitoring.

[0173] This system integrates and calibrates scene information, behavioral events, claim data, and behavioral graph node data collected at each stage. By jointly processing scene recognition results, behavioral data collection, claim consistency analysis results, and behavioral graph reasoning information, it effectively eliminates redundant records, contradictory events, and invalid behaviors, ensuring the accuracy and consistency of multi-source data across time, semantic, and graph structure dimensions. Furthermore, the system uses the integrated data to construct complete behavioral chains and malicious behavior evidence chains, generating comprehensive detection reports that include scene change processes, sensitive behavior sequences, claim consistency analysis, risk node scoring, and malicious path structures. This provides users with interpretable, traceable, and comprehensive malicious behavior monitoring data.

[0174] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for detecting malicious behavior in mobile applications based on scene context, characterized in that... Includes the following steps: Step 1: Collect multi-source information during application runtime, identify application runtime scenarios, and obtain scenario sequences; Step 2: Capture sensitive behaviors in real time through dynamic behavior capture. The sensitive behaviors are accompanied by scene tags, timestamps and call parameters, and are processed into behavior sequences through standardized cleaning. Step 3: Extract semantic information from the manifest permission declaration and privacy policy text through declaration semantic parsing, construct declaration triples, and perform declaration consistency determination; Step 4: Based on the above scenario sequence, behavior sequence and declaration triples, perform behavior graph modeling, construct application behavior graph, calculate multiple risk indicators of nodes in the application behavior graph, perform weighted summation to obtain the malicious score; Step 5: Filter high-risk nodes and paths with malicious scores exceeding the threshold, generate evidence nodes based on the time of occurrence, the scene, sensitive API calls, data flow information, and declaration conflicts. The evidence nodes are linked together in the execution order to form a complete evidence chain, and exported as a visual chart and text report.

2. The mobile application malicious behavior detection method based on scene context as described in claim 1, characterized in that: The specific steps of step 1 are as follows: receiving multi-source information during application runtime, including lifecycle events, UI structure changes, user interaction records, and system broadcast links; constructing a set of events to be identified; using a lightweight HEAD request to obtain response header information; generating a preliminary scene sequence and tags based on event type and triggering order, including foreground interaction scenarios, background silent update scenarios, sensitive permission request scenarios, data upload scenarios, and message response scenarios; cleaning the preliminary scene sequence, removing invalid events, eliminating redundant preliminary scene tags, and correcting rule conflicts; and standardizing the preliminary scene sequence to obtain a scene sequence that supports subsequent operations.

3. The mobile application malicious behavior detection method based on scene context as described in claim 1, characterized in that: Step 2 specifically involves: capturing sensitive behaviors in real time through a Hook framework, dynamic instrumentation, or sandbox mechanism, including sensitive API calls, permission usage actions, file reading behaviors, network access requests, and cross-component communication; constructing a set of behaviors to be analyzed; mapping each behavior to a structured behavior event based on its occurrence time and corresponding scene tag; and standardizing and cleaning the structured behavior events by removing invalid calls, merging repeated behaviors within a short period, restoring the true time sequence of behaviors, and unifying field formats to obtain a behavior sequence that supports subsequent operations.

4. The mobile application malicious behavior detection method based on scene context as described in claim 1, characterized in that: Step 3 specifically involves: statically parsing the manifest file to identify the permission list and registration information of sensitive components; using natural language processing methods to perform syntactic analysis and semantic extraction on the terms in the privacy policy text to obtain semantic information including the purpose of permissions, data processing methods, and scope of responsibility; and constructing structured declaration triples, which include data type, purpose, and scope of responsibility. Based on the behavior sequence, each behavior event is mapped to a behavior triple, and the semantic deviation between the declaration triple and the behavior triple is calculated, i.e., the declaration deviation degree. When the semantic deviation exceeds a set threshold, the behavior event is marked as a declaration inconsistency behavior and written into the abnormal event set as the input part for subsequent application of behavior graph reasoning.

5. The mobile application malicious behavior detection method based on scene context as described in claim 4, characterized in that: The calculation of semantic bias specifically involves: converting the declaration triples and behavior triples into standardized semantic text, encoding the semantic text of the declaration triples, and obtaining a set of declaration semantic vectors. ， in, Represents a semantic vector model. To declare the semantic text representing the data type in the triple, To declare the semantic text in the triple that indicates the purpose of the data, To declare the semantic text in the triple that represents the scope of responsibility; Encoding the semantic text of the behavior triples yields a set of behavior semantic vectors: ， in, The semantic text representing the data type in the behavior triple. The semantic text in the behavior triple that represents the purpose of the data. The semantic text representing the scope of responsibility in the behavior triple; Based on the distance or similarity relationship between semantic vectors, the semantic similarity between the declaration triples and the behavior triples is calculated across each field dimension. Cosine similarity is used as the measure of semantic similarity, and the results are as follows: ； ； ； in, , , These represent semantic similarity in terms of data type, data purpose, and scope of responsibility, respectively. The semantic similarity of each field dimension is weighted and fused to obtain the overall semantic consistency score between the declaration and the behavior: ， in, To declare a triple, For behavior triples, , , Let be the weight coefficient of the corresponding field, and satisfy . ; Based on this, the semantic deviation between declaration and behavior is defined as: ； When the same application corresponds to multiple declaration triples, for each row triple, its semantic consistency score is calculated among all declaration triples, and the maximum value is selected as the overall semantic consistency score for that row: ， And calculate the corresponding semantic bias accordingly: 。 6. The mobile application malicious behavior detection method based on scene context as described in claim 1, characterized in that: The specific steps of step 4 are as follows: Based on the scenario sequence, behavior sequence and declaration triples, perform behavior graph modeling to construct an application behavior graph. Calculate multiple risk indicators for each node in the application behavior graph, including degree centrality, betweenness centrality, behavior deviation, declaration deviation and sensitive API operation weight. Sum the risk indicators according to preset weights to obtain a malicious score. Use the malicious score result as the basis for ranking node risks.

7. The mobile application malicious behavior detection method based on scene context as described in claim 6, characterized in that: The calculation of multiple risk indicators specifically involves: Behavior deviation calculation: Based on the scene sequence, a set of expected behaviors is pre-determined for each scene. When a node is a behavior / API node, the behavior corresponding to that node is represented as... And calculate its behavioral deviation relative to the current scene: ， in, For the set of expected behaviors, This represents a measure of behavioral similarity, achieved through category matching, rule matching, or semantic similarity. Betweenness centrality calculation: Based on the topology calculation of the behavioral graph, the betweenness centrality of a node is used to measure its bridging role in the behavioral chain. The calculation formula is as follows: ， in, Indicates from node To the node The number of shortest paths, Indicates passing through nodes The number of shortest paths; Sensitive API operation weight calculation: A set of sensitive APIs and a set of sensitive data types are preset. When a node is associated with a sensitive API or sensitive data, a sensitive API operation weight is assigned to it. ， in, This represents the sensitivity level mapping value. If a node is involved in both sensitive data access and external transmission, its sensitive API operation weight is increased. ， in, This is an additional boost to the multiplier; Degree centrality calculation: Based on the application behavioral graph topology, the degree centrality of a node is calculated, which is defined as the sum of the node's in-degree and out-degree. ， in, Indicates pointing to a node The number of edges, Indicates from node The number of edges emitted.

8. The mobile application malicious behavior detection method based on scene context as described in claim 1, characterized in that: The specific steps of step 5 are as follows: Select behavioral nodes whose malicious scores exceed the threshold from the set of high-risk nodes, and restore the complete time-series chain generated by the behavior according to its associated behavioral path. Convert the behavioral nodes into evidence nodes and record the information therein, including timestamp, scene, API called, data type involved, content of conflict declaration, and malicious score. Connect multiple evidence nodes in time sequence to form an evidence chain, and output the evidence chain and malicious behavior report, including a behavior path visualization diagram, explanation of conflict declaration, and details of malicious score.

9. A mobile application malicious behavior detection system based on scene context, characterized in that: A component for implementing the method of any one of claims 1 to 8 includes the following modules: Scene recognition and behavior acquisition module: used to collect event sequences, identify application running scenarios, capture dynamic behaviors, and standardize behavior processing; Declaration Consistency and Behavior Graph Analysis Module: Used for declaration semantic parsing and triple modeling, comparing declarations with behaviors, constructing application behavior graphs, and calculating multi-dimensional maliciousness scores for nodes in the behavior graph; Explainable Evidence Chain Generation Module: Filters high-risk nodes, reconstructs the temporal chain of their related behaviors, generates a structured evidence chain composed of evidence nodes, and outputs visual charts and text reports.

Images