A method for locating mobile application sensor-triggered advertisement logic based on static analysis

Abstract

The application discloses a mobile application sensor trigger type advertisement logic positioning method based on static analysis, belongs to the technical field of mobile application security and program static analysis, and comprises two core stages of preprocessing screening and mixed positioning. In the first stage, a multi-strategy decoder containing Base64, hexadecimal and XOR operation is used to carry out string de-obfuscation on source code, so that readable code context is generated; then, multi-stage filtering is carried out based on sensor API key features and lightweight syntax structure, so that candidate class files are quickly locked. In the second stage, a standard behavior sequence of sensor data flow conversion is defined, and a mapping rule of the standard behavior sequence and an abstract syntax tree node is established. AST sub-tree matching is carried out on the code with complete structure to confirm the logic; and semantic feature analysis based on regular features is started for the obfuscated code with blocked AST analysis. The application accurately outputs the specific code position of the sensor trigger type advertisement logic, and solves the problems of difficult positioning and high false positive rate of existing tools in the code obfuscation environment.

Description

Technical Field

[0001] This invention belongs to the field of mobile application security and static program analysis technology, and specifically relates to a static positioning method for sensor-triggered ad redirection logic in Android applications under code obfuscation environment. Background Technology

[0002] With the booming development of the mobile internet ecosystem, mobile application advertising formats are constantly evolving. Among them, "shake-to-open screen" ads, as a new form of interactive advertising, are widely used in various mobile applications. This technology uses the accelerometer or gyroscope of the mobile device to detect the user's shaking behavior. Once the device shakes, it automatically redirects the user to a third-party e-commerce platform or advertising page.

[0003] However, some app developers, in pursuit of higher ad click-through rates, set extremely low trigger thresholds, making it highly susceptible to accidental touches during everyday activities like walking or riding in public transportation—activities not driven by user intent. This highly sensitive triggering logic not only severely impacts user experience but also draws attention from regulatory agencies regarding user rights protection. Currently, relevant industry standards have set clear requirements for the triggering parameters of "shake" ads, but efficiently and accurately detecting whether apps are violating regulations remains a significant challenge. Furthermore, research on this type of sensor-triggered logic is currently scarce.

[0004] Existing detection technologies have the following main problems when analyzing the triggering logic of such sensors: 1) To prevent reverse engineering, modern mobile applications commonly employ code obfuscation techniques (such as class name obfuscation, string encryption, and control flow flattening). Traditional static analysis methods based on keyword matching become completely ineffective when faced with encoded or encrypted strings, resulting in a large number of missed detections.

[0005] 2) Sensor-triggered ad redirection logic is not a single API call, but a series of continuous data processing flows. Existing taint analysis tools for sensors struggle to accurately characterize this specific business logic pattern, easily misclassifying normal sensor usage as ad logic.

[0006] 3) Most current automated detection tools focus on privacy leaks or malicious code, and lack the ability to specifically locate sensor interaction logic.

[0007] Therefore, there is an urgent need for a static analysis method that can resist code obfuscation and deeply understand the semantics of sensor data processing, in order to achieve accurate positioning of sensor-triggered advertising logic in mobile applications. Summary of the Invention

[0008] The present invention proposes a static analysis-based method for locating sensor-triggered advertising logic in mobile applications to address the aforementioned technical problems. This invention overcomes the limitations of traditional methods in the face of obfuscated code through three stages: preprocessing deobfuscation, multi-level filtering, and hybrid feature localization. First, key strings in the code are restored using a specific decoding strategy; second, the analysis scope is narrowed based on the inherent characteristics of the sensor programming framework; finally, by combining structured abstract syntax tree (AST) matching with anti-obfuscation semantic feature analysis, precise targeting of the target logic is achieved.

[0009] To achieve the above objectives, the present invention adopts the following technical solution: A sensor-triggered advertising logic positioning method for mobile applications based on static analysis, comprising: 1) Apply preprocessing and code deobfuscation methods: Step S101: Obtain the installation package M of the mobile application to be detected, use a decompilation tool to convert it into a set of source code files S, and initialize a set S' for storing the processed code; Step S102: Traverse each source code file in set S, apply the preset decoding strategy library to restore and replace the encoded strings in the source code file, and store the deobfuscated code that enhances readability into set S'; 2) Candidate class selection method based on key features: Step S103: Define the primary feature set of the sensor logic. The set S' obtained in step S102 is scanned at the file level to filter out files containing primary features, forming a preliminary set. ; Step S104: Process the initial screening set formed in step S103. The files in the dataset undergo lightweight syntax analysis to check for the existence of a complete Android sensor monitoring chain, and files that meet the criteria are added to the collection as candidate files. ; 3) Sensor data usage pattern construction method: Step S105: Define the standard sequence of behaviors for the flow of sensor data in the code. The sequence consists of five ordered operation nodes: numerical acquisition, mathematical operation, variable assignment, condition judgment, and action triggering. Step S106: Construct Abstract Syntax Tree (AST) nodes and standard behavior sequences The mapping rules for operation nodes map "numerical acquisition" to array access nodes and "mathematical operation" to mathematical method call nodes, thus constructing a structured template for subsequent matching. 4) Hybrid localization method combining structured and semantic features: Step S107: Analyze the candidate class set For each file in the process, an abstract syntax tree T is constructed. Based on the structured template established in step S106, subtree traversal and matching are performed on T. If a complete matching sequence is found... If the subtree structure is such that the file contains sensor triggering logic, then it can be directly determined that the file contains sensor triggering logic.

[0010] Step S108: For files where AST construction failed or structure matching was interrupted due to code obfuscation in step S107, initiate semantic remediation analysis, extract text features related to sensor type constants, mathematical calculation symbols, and advertising-related API calls from the code, and calculate the confidence score of the code fragment according to preset weights. ; Step S109: Combining the structured matching results of step S107 with the confidence scores of step S108, if the AST match is successful or If the threshold is exceeded, the specific code location of the sensor-triggered advertising logic in the mobile application M is determined, and the location result set L is output.

[0011] Furthermore, step S102 requires constructing a decoder containing multiple strategies to decode and replacing the result in the source code context, specifically: Step S201: Initialize the string decoding strategy library, which includes Base64 encoding recognition rules, hexadecimal string recognition rules, XOR encryption restoration rules, and string concatenation restoration rules; Step S202: Perform a full-text scan of the source code file using predefined regular expressions, match string constants that conform to the encoding characteristics in the strategy library, and construct a set of strings to be decoded; Step S203: Traverse the set of strings to be decoded, apply the corresponding decoding algorithm to restore them, and perform semantic verification on the restored text. If the restored text contains sensor API keywords or readable natural language words, it is determined to be valid decoding. Step S204: Replace the original obfuscated string in the source code file with the valid decoded text obtained in step S203, generate the deobfuscated code file and store it in set S'.

[0012] Furthermore, in step S103, a primary feature set for sensor logic is defined. It is built based on the key components of the Android operating system's standard sensor access process framework, and these key components include the following four parts: 1) SensorManager: The core management class in the Android system used to access and control sensor hardware services; 2) SensorEvent: An event object in the Android system used to encapsulate raw sensor values, timestamps, and accuracy information; 3) registerListener: In the Android system, this is a specific method name used by the application to register data listening callbacks with the sensor manager; 4) onSensorChanged: The name of the core callback method defined by the SensorEventListener interface in the Android system, used to receive notifications of changes in sensor values.

[0013] Furthermore, steps S103 and S104 aim to accurately locate the relevant code files by combining coarse-grained text scanning with fine-grained syntax feature verification, specifically as follows: Step S301: Traverse each source code file in the deobfuscated code set S', perform a full text scan of the file, and if the primary feature set is matched in the file... If any keyword in the file is found, the file is marked as a preliminary screening file and added to the set. ; Step S302: For the set Each initial screening file undergoes lightweight syntax feature verification to exclude interfering files that only contain strings with the same name but have no actual logic. The verification rules are to check whether the class definition of the file explicitly implements the SensorEventListener interface, or to check whether the method body of the file contains a getSystemService method call with the parameter pointing to the sensor service. Step S303: Add the file verified in step S302 as a candidate class containing complete sensor interaction logic to the candidate class set. .

[0014] Furthermore, the standard behavioral sequence for sensor data flow defined in step S105. It is an abstract description of the general business process of sensor-triggered advertising logic, specifically represented as an ordered sequence of 5-tuples: ,in" This indicates a sequential data stream operation connecting the nodes. The nodes are defined as follows: 1) Value Acquisition Node: Refers to the operation in the code that extracts raw axial data (such as X, Y, and Z axis accelerations) from sensor event objects; 2) Mathematical operation node (Compute): refers to the physical quantity calculation operation performed on the raw data, used to convert multi-axis data into resultant acceleration or angular velocity magnitude; 3) Variable assignment node (Assign): refers to the data transfer operation that passes the calculated physical quantity result to local variables or class member variables; 4) Conditional decision node (Assign): refers to the logical branch operation that uses comparison operators to compare the above variables with a preset threshold; 5) Action trigger node: refers to the ad loading, page redirection, or pop-up display operation executed in the branch block where the conditions are met.

[0015] Furthermore, in step S106, the abstract syntax tree (AST) nodes and standard behavior sequences are established. The mapping rules specifically include: 1) Map the value acquisition nodes in the sequence to array access nodes ArraySelector or member reference nodes in the AST, and the operation object is SensorEvent.values; 2) Map the "mathematical operation nodes" in the sequence to the method invocation nodes in the AST, and their invocation names match Math.sqrt, Math.abs, or Math.pow; 3) Map the variable assignment nodes in the sequence to assignment expression nodes in the AST to track the data flow transmission path; 4) Map the condition judgment nodes in the sequence to the condition statement nodes IfStatement in the AST, and the condition expression contains the binary comparison operator BinaryOperation; 5) Map the action triggering node in the sequence to the method call node in the AST, which is located inside the execution block of the conditional statement.

[0016] Furthermore, step S107 requires performing data flow-based subtree matching on the abstract syntax tree to locate the complete logical chain that conforms to the standard behavior sequence, specifically: Step S401: Use the Java syntax parser to parse the candidate class file into an abstract syntax tree T, and traverse the tree structure to locate the method declaration node named onSensorChanged as the analysis entry point; Step S402: In the subtree of the entry node, perform a depth-first traversal according to the program execution order to search for a numerical acquisition node that conforms to the mapping rule described in claim 6; Step S403: Starting from the searched value acquisition node, trace downwards along the data flow, and match the subsequent mathematical operation nodes and variable assignment nodes in sequence to construct a local data flow chain; Step S404: Check whether the end variable of the data flow chain appears as an operand in a condition judgment node. If it does, further check whether there is an action triggering node in the execution block of the condition node.

[0017] Step S405: If the above nodes are in sequence If the sequence of events appears completely and forms a closed loop, then the file is determined to contain specific sensor-triggered advertising logic, and the line number range of this logic in the source code is recorded.

[0018] Furthermore, step S108 requires analyzing the code where AST parsing is blocked using a semantic feature extraction method, specifically as follows: Step S501: Construct a semantic feature regular expression library, which contains four types of feature patterns: sensor registration pattern, sensor type reference pattern, data callback method signature pattern, and motion calculation logic pattern; Step S502: Use the regular expression library to perform a full-text scan of the code to be analyzed, count the matching hits of various feature patterns, and generate feature vectors. Each component represents the presence or frequency of the corresponding feature; Step S503: Calculate the confidence score of the code snippet based on the preset heuristic weighting model. The calculation formula is: .in, For the first Weight coefficients of class features This is a penalty factor calculated based on the degree of code obfuscation. Step S504: If the calculated confidence score Exceeding the preset judgment threshold If so, the code snippet is marked as a "suspected sensor-triggered logic snippet" and its confidence value is recorded.

[0019] Furthermore, step S109 requires a strategy that prioritizes structured confirmation and complements semantic inference to comprehensively determine whether the candidate fragment contains sensor-triggered ad redirection logic, specifically as follows: Step S601: Initialize the location result set L to be empty; Step S602: Traverse the candidate class set, prioritizing the AST structured matching results from step S104. If a complete matching standard behavior sequence exists... The code file is directly added to the result set L, and the detection method is marked as "structured verification"; Step S603: For files that fail to match the AST, check the confidence score calculated in step S105. ,like Add it to the result set L and label the detection method as "semantic inference"; Step S604: Generate a location report for each item in the result set L. The report includes the package name, class name, method name where the triggering logic is located, code line number range, and corresponding detection confidence.

[0020] A further improvement of the present invention is that: in step S102, a library of multiple decoding strategies including Base64, hexadecimal and XOR operations is constructed, and a semantic verification mechanism is introduced, which can effectively resist common string encryption and obfuscation techniques in mobile applications and provide a readable code context for subsequent analysis.

[0021] A further improvement of the present invention is that steps S105 and S106 propose a universal sensor data usage mode. This abstract pattern is then mapped to specific AST node features. This design shields the differences in code implementation details between different applications, making the detection method more universal and robust.

[0022] A further improvement of the present invention is that step S109 employs a hybrid decision-making strategy of "prioritizing structured verification and complementing semantic inference". For code with complete structure, AST is used first for precise matching to ensure accuracy; for code with damaged structure or severe obfuscation, it is automatically downgraded to a semantic inference mode based on weighted features, thereby significantly improving the recall rate of anti-obfuscated code while ensuring detection accuracy.

[0023] Compared with the prior art, the present invention has the following advantages: 1) To address the problem that existing static analysis tools are prone to failure when faced with code obfuscation, this invention uses pre-processing string deobfuscation and post-processing semantic feature-based analysis to accurately identify sensor triggering logic even when the AST structure is destroyed or variable names are obfuscated, effectively solving the problem of missed detections.

[0024] 2) This invention does not merely rely on the existence of sensor API calls for judgment, but delves into the complete flow path of sensor data (from data acquisition to triggering action). It matches standard behavioral sequences. It can effectively distinguish between ordinary code containing sensor functions and real sensor-triggered advertising logic, significantly reducing the false alarm rate.

[0025] 3) This invention designs a primary screening mechanism based on key features. Before performing high-overhead AST parsing and data stream tracing, a large number of irrelevant files are pre-filtered out, which greatly shortens the overall detection time for large mobile applications and is suitable for large-scale batch detection scenarios. Attached Figure Description

[0026] Figure 1 This is an overall flowchart of the present invention; Figure 2 This is a flowchart illustrating the preprocessing and code deobfuscation processes used in this invention. Figure 3 This is a flowchart of the candidate class screening process based on key features according to the present invention; Figure 4 This is a flowchart of the structured AST analysis process of the present invention; Figure 5 This is a flowchart of the semantic feature extraction process of the present invention; Figure 6 This is a flowchart illustrating the hybrid decision-making process of the present invention. Detailed Implementation The following detailed description, in conjunction with the accompanying drawings, illustrates a specific implementation method for an app sensor-triggered advertising logic positioning method based on static analysis.

[0027] Reference Figure 1 As shown, this invention discloses a method for locating APP sensor-triggered advertising logic based on static analysis, including the following steps: Step S101: Obtain the installation package M of the mobile application to be detected, use a decompilation tool to convert it into a set of source code files S, and initialize a set S' for storing the processed code; Step S102: Traverse each source code file in set S, apply the preset decoding strategy library to restore and replace the encoded strings in the source code file, and store the deobfuscated code that enhances readability into set S'; Reference Figure 2 As shown, specifically, it can be divided into the following steps: Step S201: Initialize the string decoding strategy library, which includes Base64 encoding recognition rules, hexadecimal string recognition rules, XOR encryption restoration rules, and string concatenation restoration rules; Step S202: Perform a full-text scan of the source code file using predefined regular expressions, match string constants that conform to the encoding characteristics in the strategy library, and construct a set of strings to be decoded; Step S203: Traverse the set of strings to be decoded, apply the corresponding decoding algorithm to restore them, and perform semantic verification on the restored text. If the restored text contains sensor API keywords or readable natural language words, it is determined to be valid decoding. Step S204: Replace the original obfuscated string in the source code file with the valid decoded text obtained in step S203, generate the deobfuscated code file and store it in set S'.

[0028] Step S103: Define the primary feature set of the sensor logic. The set S' obtained in step S102 is scanned at the file level to filter out files containing primary features, forming a preliminary set. ; Specifically, step S103 defines the primary feature set of the sensor logic. It is built based on the key components of the Android operating system's standard sensor access process framework, and these key components include the following four parts: 1) SensorManager: The core management class in the Android system used to access and control sensor hardware services; 2) SensorEvent: An event object in the Android system used to encapsulate raw sensor values, timestamps, and accuracy information; 3) registerListener: In the Android system, this is a specific method name used by the application to register data listening callbacks with the sensor manager; 4) onSensorChanged: The name of the core callback method defined by the SensorEventListener interface in the Android system, used to receive notifications of changes in sensor values.

[0029] Step S104: Process the initial screening set formed in step S103. The files in the dataset undergo lightweight syntax analysis to check for the existence of a complete Android sensor monitoring chain, and files that meet the criteria are added to the collection as candidate files. ; Reference Figure 3 As shown, specifically, steps S103 and S104 aim to accurately locate the relevant code files by combining coarse-grained text scanning with fine-grained syntax feature verification, specifically as follows: Step S301: Traverse each source code file in the deobfuscated code set S', perform a full text scan of the file, and if the primary feature set is matched in the file... If any keyword in the file is found, the file is marked as a preliminary screening file and added to the set. ; Step S302: For the set Each initial screening file undergoes lightweight syntax feature verification to exclude interfering files that only contain strings with the same name but have no actual logic. The verification rules are to check whether the class definition of the file explicitly implements the SensorEventListener interface, or to check whether the method body of the file contains a getSystemService method call with the parameter pointing to the sensor service. Step S303: Add the file verified in step S302 as a candidate class containing complete sensor interaction logic to the candidate class set. .

[0030] Step S105: Define the standard sequence of behaviors for the flow of sensor data in the code. The sequence consists of five ordered operation nodes: numerical acquisition, mathematical operation, variable assignment, condition judgment, and action triggering. Specifically, the standard behavioral sequence of sensor data flow defined in step S105 It is an abstract description of the general business process of sensor-triggered advertising logic, specifically represented as an ordered sequence of 5-tuples: ,in" This indicates a sequential data stream operation connecting the nodes. The nodes are defined as follows: 1) Value Acquisition Node: Refers to the operation in the code that extracts raw axial data (such as X, Y, and Z axis accelerations) from sensor event objects; 2) Mathematical operation node (Compute): refers to the physical quantity calculation operation performed on the raw data, used to convert multi-axis data into resultant acceleration or angular velocity magnitude; 3) Variable assignment node (Assign): refers to the data transfer operation that passes the calculated physical quantity result to local variables or class member variables; 4) Conditional decision node (Assign): refers to the logical branch operation that uses comparison operators to compare the above variables with a preset threshold; 5) Action trigger node: refers to the ad loading, page redirection, or pop-up display operation executed in the branch block where the conditions are met.

[0031] Step S106: Construct Abstract Syntax Tree (AST) nodes and standard behavior sequences The mapping rules for operation nodes map "numerical acquisition" to array access nodes and "mathematical operation" to mathematical method call nodes, thus constructing a structured template for subsequent matching. Specifically, in step S106, the Abstract Syntax Tree (AST) nodes and standard behavior sequences are established. The mapping rules specifically include: 1) Map the value acquisition nodes in the sequence to array access nodes ArraySelector or member reference nodes in the AST, and the operation object is SensorEvent.values; 2) Map the "mathematical operation nodes" in the sequence to the method invocation nodes in the AST, and their invocation names match Math.sqrt, Math.abs, or Math.pow; 3) Map the variable assignment nodes in the sequence to assignment expression nodes in the AST to track the data flow transmission path; 4) Map the condition judgment nodes in the sequence to the condition statement nodes IfStatement in the AST, and the condition expression contains the binary comparison operator BinaryOperation; 5) Map the action triggering node in the sequence to the method call node in the AST, which is located inside the execution block of the conditional statement.

[0032] Step S107: Analyze the candidate class set For each file in the process, an abstract syntax tree T is constructed. Based on the structured template established in step S106, subtree traversal and matching are performed on T. If a complete matching sequence is found... If the subtree structure is such that the file contains sensor triggering logic, then it can be directly determined that the file contains sensor triggering logic.

[0033] Reference Figure 4 As shown, specifically, step S107 requires performing data flow-based subtree matching on the abstract syntax tree to locate the complete logical chain that conforms to the standard behavior sequence, specifically as follows: Step S401: Use the Java syntax parser to parse the candidate class file into an abstract syntax tree T, and traverse the tree structure to locate the method declaration node named onSensorChanged as the analysis entry point; Step S402: In the subtree of the entry node, perform a depth-first traversal according to the program execution order to search for a numerical acquisition node that conforms to the mapping rule described in claim 6; Step S403: Starting from the searched value acquisition node, trace downwards along the data flow, and match the subsequent mathematical operation nodes and variable assignment nodes in sequence to construct a local data flow chain; Step S404: Check whether the end variable of the data flow chain appears as an operand in a condition judgment node. If it does, further check whether there is an action triggering node in the execution block of the condition node.

[0034] Step S405: If the above nodes are in sequence If the sequence of events appears completely and forms a closed loop, then the file is determined to contain specific sensor-triggered advertising logic, and the line number range of this logic in the source code is recorded.

[0035] Step S108: For files where AST construction failed or structure matching was interrupted due to code obfuscation in step S107, initiate semantic feature analysis, extract text features related to sensor type constants, mathematical calculation symbols, and advertising-related API calls from the code, and calculate the confidence score of the code segment according to preset weights. ; Reference Figure 5 As shown, specifically, step S108 requires using a semantic feature extraction method to analyze the code where AST parsing is blocked, specifically as follows: Step S501: Construct a semantic feature regular expression library, which contains four types of feature patterns: sensor registration pattern, sensor type reference pattern, data callback method signature pattern, and motion calculation logic pattern; Step S502: Use the regular expression library to perform a full-text scan of the code to be analyzed, count the matching hits of various feature patterns, and generate feature vectors. Each component represents the presence or frequency of the corresponding feature; Step S503: Calculate the confidence score of the code snippet based on the preset heuristic weighting model. The calculation formula is: .in, For the first Weight coefficients of class features This is a penalty factor calculated based on the degree of code obfuscation. Step S504: If the calculated confidence score Exceeding the preset judgment threshold If so, the code snippet is marked as a "suspected sensor-triggered logic snippet" and its confidence value is recorded.

[0036] Step S109: Combining the structured matching results of step S107 with the confidence scores of step S108, if the AST match is successful or If the threshold is exceeded, the specific code location of the sensor-triggered advertising logic in the mobile application M is determined, and the location result set L is output.

[0037] Reference Figure 6 As shown, specifically, step S109 requires a strategy of prioritizing structured confirmation and complementing semantic inference to comprehensively determine whether the candidate fragment contains sensor-triggered ad redirection logic, specifically as follows: Step S601: Initialize the location result set L to be empty; Step S602: Traverse the candidate class set, prioritizing the AST structured matching results from step S104. If a complete matching standard behavior sequence exists... The code file is directly added to the result set L, and the detection method is marked as "structured verification"; Step S603: For files that fail to match the AST, check the confidence score calculated in step S105. ,like Add it to the result set L and label the detection method as "semantic inference"; Step S604: Generate a location report for each item in the result set L. The report includes the package name, class name, method name where the triggering logic is located, code line number range, and corresponding detection confidence.

Claims

1. A method for locating sensor-triggered advertising logic in mobile applications based on static analysis, characterized in that, Includes the following steps: 1) Apply preprocessing and code deobfuscation methods: Step S101: Obtain the installation package M of the mobile application to be detected, use a decompilation tool to convert it into a set of source code files S, and initialize a set S' for storing the processed code; Step S102: Traverse each source code file in set S, apply the preset decoding strategy library to restore and replace the encoded strings in the source code file, and store the deobfuscated code that enhances readability into set S'; 2) Candidate class selection method based on key features: Step S103: Define the primary feature set of the sensor logic. The set S' obtained in step S102 is scanned at the file level to filter out files containing primary features, forming a preliminary set. ; Step S104: Process the initial screening set formed in step S103. The files in the dataset undergo lightweight syntax analysis to check for the existence of a complete Android sensor monitoring chain, and files that meet the criteria are added to the collection as candidate files. ; 3) Sensor data usage pattern construction method: Step S105: Define the standard sequence of behaviors for the flow of sensor data in the code. The sequence consists of five ordered operation nodes: numerical acquisition, mathematical operation, variable assignment, condition judgment, and action triggering. Step S106: Construct Abstract Syntax Tree (AST) nodes and standard behavior sequences The mapping rules for operation nodes in the middle map numerical acquisition to array access nodes and mathematical operations to mathematical method call nodes, thus constructing a structured template for subsequent matching; 4) Hybrid localization method combining structured and semantic features: Step S107: Analyze the candidate class set For each file in the process, an abstract syntax tree T is constructed. Based on the structured template established in step S106, subtree traversal and matching are performed on T. If a complete matching sequence is found... If the subtree structure is such that the file contains sensor triggering logic, then it can be directly determined that the file contains sensor triggering logic. Step S108: For files where AST construction failed or structure matching was interrupted due to code obfuscation in step S107, initiate semantic feature analysis, extract text features related to sensor type constants, mathematical calculation symbols, and advertising-related API calls from the code, and calculate the confidence score of the code segment according to preset weights. ; Step S109: Combining the structured matching results of step S107 with the confidence scores of step S108, if the AST match is successful or If the threshold is exceeded, the specific code location of the sensor-triggered advertising logic in the mobile application M is determined, and the location result set L is output.

2. The method according to claim 1, characterized in that, Step S102 requires constructing a decoder with multiple strategies to decode the code and replacing the result with the source code context, specifically: Step S201: Initialize the string decoding strategy library, which includes Base64 encoding recognition rules, hexadecimal string recognition rules, XOR encryption restoration rules, and string concatenation restoration rules; Step S202: Perform a full-text scan of the source code file using predefined regular expressions, match string constants that conform to the encoding characteristics in the strategy library, and construct a set of strings to be decoded; Step S203: Traverse the set of strings to be decoded, apply the corresponding decoding algorithm to restore them, and perform semantic verification on the restored text. If the restored text contains sensor API keywords or readable natural language words, it is determined to be valid decoding. Step S204: Replace the original obfuscated string in the source code file with the valid decoded text obtained in step S203, generate the deobfuscated code file and store it in set S'.

3. The method according to claim 1, characterized in that, In step S103, the primary feature set of the sensor logic is defined. It is built based on the key components of the Android operating system's standard sensor access process framework, and these key components include the following four parts: 1) SensorManager: The core management class in the Android system used to access and control sensor hardware services; 2) SensorEvent: An event object in the Android system used to encapsulate raw sensor values, timestamps, and accuracy information; 3) registerListener: In the Android system, this is a specific method name used by the application to register data listening callbacks with the sensor manager; 4) onSensorChanged: The name of the core callback method defined by the SensorEventListener interface in the Android system, used to receive notifications of changes in sensor values.

4. The method according to claim 1, characterized in that, Steps S103 and S104 aim to accurately locate the relevant code files by combining coarse-grained text scanning with fine-grained syntax feature verification. Specifically: Step S301: Traverse each source code file in the deobfuscated code set S', perform a full text scan of the file, and if the primary feature set is matched in the file... If any keyword in the file is found, the file is marked as a preliminary screening file and added to the set. ; Step S302: For the set Each initial screening file undergoes lightweight syntax feature verification to exclude interfering files that only contain strings with the same name but have no actual logic. The verification rules are to check whether the class definition of the file explicitly implements the SensorEventListener interface, or to check whether the method body of the file contains a getSystemService method call with the parameter pointing to the sensor service. Step S303: Add the file verified in step S302 as a candidate class containing complete sensor interaction logic to the candidate class set. .

5. The method according to claim 1, characterized in that, The standard behavioral sequence of sensor data flow defined in step S105 It is an abstract description of the general business process of sensor-triggered advertising logic, specifically represented as an ordered sequence of 5-tuples: The connector between nodes indicates the sequential data stream operation that connects the nodes.

6. The method according to claim 5, characterized in that, The definitions of each node are as follows: 1) Value node: refers to the operation in the code that extracts raw axial data from the sensor event object; 2) Mathematical operation node Compute: refers to the physical quantity calculation operation performed on the raw data, used to convert multi-axis data into resultant acceleration or angular velocity magnitude; 3) Variable assignment node Assign: refers to the data transfer operation that passes the calculated physical quantity result to local variables or class member variables; 4) Conditional decision node Assign: refers to the logical branch operation that uses comparison operators to compare the above variables with a preset threshold; 5) Action trigger node: refers to the ad loading, page redirection, or pop-up display operation executed in the branch block where the conditions are met.

7. The method according to claim 1, characterized in that, In step S106, the Abstract Syntax Tree (AST) nodes and standard behavior sequences are established. The mapping rules specifically include: 1) Map the value acquisition nodes in the sequence to array access nodes ArraySelector or member reference nodes in the AST, and the operation object is SensorEvent.values; 2) Map the mathematical operation nodes in the sequence to the method invocation nodes in the AST, and their invocation names match Math.sqrt, Math.abs, or Math.pow; 3) Map the variable assignment nodes in the sequence to assignment expression nodes in the AST to track the data flow transmission path; 4) Map the condition judgment nodes in the sequence to the condition statement nodes IfStatement in the AST, and the condition expression contains the binary comparison operator BinaryOperation; 5) Map the action triggering node in the sequence to the method call node in the AST, which is located inside the execution block of the conditional statement.

8. The method according to claim 1, characterized in that, Step S107 requires performing data flow-based subtree matching on the abstract syntax tree to locate the complete logical chain that conforms to the standard behavior sequence, specifically: Step S401: Use the Java syntax parser to parse the candidate class file into an abstract syntax tree T, and traverse the tree structure to locate the method declaration node named onSensorChanged as the analysis entry point; Step S402: In the subtree of the entry node, perform a depth-first traversal according to the program execution order to search for a numerical acquisition node that conforms to the mapping rule described in claim 6; Step S403: Starting from the searched value acquisition node, trace downwards along the data flow, and match the subsequent mathematical operation nodes and variable assignment nodes in sequence to construct a local data flow chain; Step S404: Check whether the end variable of the data flow chain appears as an operand in a condition judgment node. If it does, further check whether there is an action triggering node in the execution block of the condition node. Step S405: If the above nodes are in sequence If the sequence of events appears completely and forms a closed loop, then the file is determined to contain specific sensor-triggered advertising logic, and the line number range of this logic in the source code is recorded.

9. The method according to claim 1, characterized in that, Step S108 requires analyzing the code where AST parsing is blocked using a semantic feature extraction method, specifically: Step S501: Construct a semantic feature regular expression library, which contains four types of feature patterns: sensor registration pattern, sensor type reference pattern, data callback method signature pattern, and motion calculation logic pattern; Step S502: Use the regular expression library to perform a full-text scan of the code to be analyzed, count the matching hits of various feature patterns, and generate feature vectors. Each component represents the presence or frequency of the corresponding feature; Step S503: Calculate the confidence score of the code snippet based on the preset heuristic weighting model. The calculation formula is: ,in, For the first Weight coefficients of class features This is a penalty factor calculated based on the degree of code obfuscation. Step S504: If the calculated confidence score Exceeding the preset judgment threshold If so, the code snippet is marked as a suspected sensor-triggered logic snippet, and its confidence value is recorded.

10. The method according to claim 1, characterized in that, Step S109 requires a strategy of prioritizing structured verification and complementing semantic inference to comprehensively determine whether the candidate fragment contains sensor-triggered ad redirection logic. Specifically: Step S601: Initialize the location result set L to be empty; Step S602: Traverse the candidate class set, prioritizing the AST structured matching results from step S104. If a complete matching standard behavior sequence exists... The code file is directly added to the result set L, and the detection method is marked as structured verification; Step S603: For files that fail to match the AST, check the confidence score calculated in step S105. ,like Add it to the result set L and mark the detection method as semantic inference; Step S604: Generate a location report for each item in the result set L. The report includes the package name, class name, method name where the triggering logic is located, code line number range, and corresponding detection confidence.

Images