An overlay guide-based multi-entry test method for Android application

Abstract

The application discloses a kind of multi-entry test methods based on coverage guidance for Android application, comprising: firstly, the path constraint related to intent attribute is extracted to Android application by executing static analysis, and suitable attribute value is generated for intent attribute by analyzing different constraints, then fuzzy Activity startup context is constructed in combination with intent fuzzing technology;Then a dynamic Activity recommendation algorithm is designed according to the characteristics of multi-entry test, then an adaptive multi-entry exploration strategy is realized in combination with exploration tool APE;Finally, the idea of grey-box fuzzing test guided by coverage is introduced, and a multi-entry test method based on coverage guidance is realized.The method of the application can effectively improve the test efficiency of application program, and successfully detect potential errors difficult to find in program.

Description

Technical Field

[0001] The present invention belongs to the technical field of application error / fault detection, and in particular relates to a coverage-guided multi-entry testing method for Android applications. Background Art

[0002] To meet market demand and competitive pressures, mobile applications are often launched quickly and updated frequently. This can lead to a series of bug / fault detection issues, such as fragmented version compatibility, imperfect error handling and fault tolerance mechanisms, exploitation of security vulnerabilities, and insufficient test coverage. If these issues are not discovered and fixed promptly, they can result in severe financial losses. Therefore, improving the stability, reliability, and security of Android applications is crucial. To address these challenges, researchers are actively exploring suitable solutions.

[0003] In recent years, a large number of researchers have focused on improving application test coverage to uncover more potential errors and faults. They have proposed numerous advanced testing techniques and tools aimed at improving application quality and user experience. These techniques specifically include test case generation, test case selection, test case reuse, and test case recording and reproduction methods. Compared to traditional manual testing methods, these techniques can be combined with automated testing methods, fully utilizing test cases to automatically generate random or rule- and scenario-based event sequences. By injecting these events into applications, they can closely simulate the user interaction process with the application, thereby covering different functional scenarios, achieving automated crash localization, and promising verification of the correctness and compatibility of applications on multiple Android versions.

[0004] Fuzz testing, on the other hand, is a widely used testing method that facilitates the discovery and remediation of security vulnerabilities in mobile applications, offering significant advantages for improving the security and robustness of applications. It can effectively detect security vulnerabilities such as buffer overflows, malicious code injection, and cross-site scripting attacks, as well as crashes caused by numeric format exceptions, null pointer exceptions, and array out-of-bounds exceptions. Depending on how the input is generated, fuzz testing is generally divided into generation-based fuzz testing and mutation-based fuzz testing. The core idea of ​​traditional fuzz testing is to inject randomly generated or mutated input data into the target application to discover security vulnerabilities and abnormal behavior that may occur when the application handles abnormal or invalid input. However, it is a black-box testing method that lacks understanding of the internal structure of the target program. To address this shortcoming, researchers have developed gray-box fuzz testing by monitoring and analyzing the internal execution of the target application.

[0005] Furthermore, researchers have combined the advantages of program analysis to apply fuzz testing techniques to Android's ICC mechanism, achieving significant progress in the field of inter-process communication fuzz testing. Since the advent of the nullintent fuzzer, researchers have increasingly leveraged fuzz testing to detect security issues related to application intent handling, such as intent injection, malicious intent hijacking, and intent parsing vulnerabilities. Representative works include Intent Fuzzer, IntentDroid, and FuzzDroid. These tools leverage program analysis techniques such as static analysis, dynamic analysis, or local symbolic execution. Using control flow graphs and data flow graphs, they extract intent-related attribute values ​​from application bytecode and configuration files. By combining random value generation and mutation methods, they successfully construct fuzzed intent test cases. However, due to their limited use of simple program analysis methods, these methods cannot guarantee the integrity of the constructed intent test cases, resulting in missing structures and attributes, which can lead to a failure to cover important application functionality. Furthermore, these methods fail to consider diverse execution paths and conditional branches, making them path-insensitive and unable to guide the program to trigger more paths or access deeper code locations.

[0006] To achieve this research goal, some cutting-edge researchers have proposed innovative solutions such as Fax and DALT. They use symbolic execution to conduct activity startup testing and improve some of the shortcomings of symbolic execution. By using the SMT solver to solve the path constraints related to ICC, ICC messages with appropriate attribute values ​​are generated, and effective intent test cases are thus constructed. Although these methods effectively improve the sensitivity of the path and further enhance the program's ability to discover deep vulnerabilities, they still cannot fully test the application and face the challenge of coverage requirements, which means that some potential errors and faults remain undetected. Moreover, when the intent attributes involve complex or special data types, the search for vulnerabilities under their related constraints will be limited. In addition, due to the use of simple value filling or mutation strategies, the generated fuzz test cases lack diversity. Summary of the Invention

[0007] The purpose of the present invention is to address the deficiencies of the existing technology and propose a coverage-guided multi-entry testing method for Android applications. The multi-entry testing method is combined with the coverage-guided gray-box fuzz testing idea, and the application code is tested for methods and branches with the help of an instrumentation tool to verify the testing efficiency of the application and detect potential errors within it.

[0008] In order to achieve the above technical objectives, the present invention adopts the following technical solutions.

[0009] A coverage-guided multi-entry testing system for Android applications includes a preprocessing module, a static analysis module, a fuzzy Activity startup context construction module, and a coverage-guided multi-entry exploration module; the preprocessing module is used to expose the Internal Activity of APK as ExportedActivity and perform method-level and branch-level detection on the exposed APK; the static analysis module is used to perform inter-procedural, context-sensitive, flow-sensitive, and path-sensitive analysis, and uses Jimple as the intermediate language of Soot to analyze the bytecode of the application to obtain inter-procedural control flow graph, method call graph, static Activity transition graph, and three program complexity features: number of statements, number of branches, and number of called method types; the fuzzy Activity startup context construction module uses symbolic execution, path reversal, and other methods to analyze the bytecode of the application, so as ... The Reversal and IntentFuzzing methods pre-mutate the generated ICC messages to construct effective intent test cases; the coverage-guided multi-entry exploration module combines the principles of coverage-guided gray-box fuzz testing, the designed Activity recommendation algorithm and the exploration tool APE to perform multi-entry testing on all exploration entries of the application in a targeted manner.

[0010] A testing method for the above-mentioned coverage-guided multi-entry testing system for Android applications includes the following steps:

[0011] Step S1: The preprocessing module uses the Android reverse engineering tool APKTool to decompile the APK file to obtain the manifest file, resource files, and Smali code information; then uses DOM to parse the decompiled manifest file and expose the component by changing the exported attribute of the Activity node; then uses the back compilation function provided by APKTool to perform signature verification and repackage the file into an executable APK;

[0012] Step S2: The pre-processing module uses the instrumentation tool to perform method-level and branch-level detection on the Smali code of the exposed APK to facilitate the statistical calculation of method coverage and branch coverage;

[0013] Step S3: The static analysis module uses Jimple as the intermediate language of Soot to analyze the bytecode of the application program, and obtains the inter-procedural control flow graph, method call graph, static activity transition graph, and three program complexity features: the number of statements, the number of branches, and the number of called method types;

[0014] Step S4: The static analysis module uses the Jadx tool to obtain the source code of the APK and then traces the API methods related to layout view loading. After obtaining the layout file bound to the Activity, it recursively traverses all resource file paths and analyzes their corresponding ElementTrees. Based on the different label nodes in the tree, the types and numbers of common UI controls are counted to obtain the characteristic value of the number of UI controls in the Activity.

[0015] Step S5: Construct a fuzzy Activity startup context module and generate ICC messages using symbolic execution; analyze the path constraints and extract key intent attribute values;

[0016] Step S6: Pass these key values ​​to the intent fuzz test program to participate in the pre-mutation process of the ICC message, and then use rich data sources to increase the diversity of test cases and generate effective fuzzy activity startup context;

[0017] Step S7: The coverage-guided multi-entry exploration module uses static analysis results and runtime information to implement an activity recommendation algorithm, and integrates the exploration tool APE to implement a dynamic multi-entry exploration strategy;

[0018] Step S8: Combine the coverage-guided grey-box fuzz testing concept to implement coverage-guided fuzz testing with feedback.

[0019] Specifically, the construction of the fuzzy Activity startup context module in step S5 and the use of symbolic execution to generate an ICC message include the following steps:

[0020] Step S51: Modeling intent objects according to different intent attribute types, where the intent attribute types include basic attribute types and additional parameter types; traversing the execution path of the application along the inter-procedural control flow graph, and analyzing the corresponding bytecode;

[0021] Step S52: Check whether the application uses a predefined method related to intent acquisition to obtain an intent reception variable;

[0022] Step S53: Use the def-use technique to track the usage points of these intent receiving variables and check whether the units where they are located use methods related to intent attribute acquisition to obtain the intent attribute receiving variables. For additional parameter types, it is also necessary to obtain their type-key fields.

[0023] Step S54: Continue to track the usage points of these intent attribute receiving variables, analyze the conditional expressions related to these variables and their intermediate transfer variables, and construct path constraints. The path constraints related to additional parameters will be used to analyze key values, and the path constraints related to basic attributes will be passed to the Z3 solver for attribute verification and solution, so as to prune infeasible paths and find potential attribute values ​​that meet the given constraints.

[0024] Step S55: After the constraint solution is completed, the basic ICC message is extracted from the solution result, which mainly includes basic attributes with specific data and additional parameters including the type-key field.

[0025] Furthermore, the analysis of the path constraints in step S5 to extract key intent attribute values ​​includes the following steps:

[0026] Step S56: extracting additional path constraints related to additional parameters along different execution paths;

[0027] Step S57: Invert the path constraints, construct different attribute paths, and reversely deduce the key values ​​that satisfy these constraints, where the key values ​​related to the basic attribute constraints are used to mutate the solved ICC message, and the key values ​​related to the additional parameter constraints are used to fill the corresponding additional parameter fields in the ICC message.

[0028] Specifically, the process of generating a valid fuzzy Activity startup context in step S6 is as follows:

[0029] Step S61: These key values ​​are passed to the intent fuzzing program, which then compares the basic attribute values ​​of the basic ICC message with the declared data in the intent filter of the target component. If a match fails, the target component to be sent is first determined, and then the data declared in the corresponding intent filter and the key values ​​extracted from the constraints are used to mutate it, generating a set of mutated ICC messages that are closer to the expected value.

[0030] Step S62: For each ICC message, data is filled in a variety of ways according to the type and key name of the additional parameter. The data sources include key values ​​related to the additional parameter constraints, fixed values, boundary values, randomly generated strings, positive and negative values, null values, and null references.

[0031] Step S63: Generate a set of fuzzy Activity startup contexts based on the name, startup flag, and communication method of the target component.

[0032] Specifically, the multi-entry exploration module based on coverage guidance in step S7 utilizes static analysis results and runtime information to implement an Activity recommendation algorithm, including the following steps:

[0033] Step S71, calculate a priority value for each Activity component, and determine the Activity with the maximum priority value, i.e., maxAct;

[0034] Step S72, determine whether maxAct is an exploration entry. If maxAct is an exploration entry, preferentially select an effective intent test case containing a key value as the recommendation result and return. If there is no such effective test case containing a key value, randomly select a test case from the effective test case set of maxAct and return. If maxAct is not an exploration entry, determine whether maxAct is an isolated node. If maxAct is an isolated node, there is no exploration entry in the ATG that can reach the node, and thus the return result of the algorithm is empty. If maxAct is not an isolated node, calculate the distances from all exploration entries to maxAct according to the Activity transition graph, and recommend a test case for the Activity with the shortest distance;

[0035] Step S73, determine whether there are multiple results with the shortest distance. If there are multiple results, calculate the average call depth from the lifecycle method and the event handling method to the intent sending method according to the method call graph, and then recommend a test case for the Activity with the shortest distance. If the result is unique, directly recommend a test case for the Activity.

[0036] Further, the integrated exploration tool APE in step S7 implements a dynamic multi-entry exploration strategy, including the following steps:

[0037] Step S74, first use APE to explore the main entry point of the application for a fixed time length to collect initial information;

[0038] Step S75, then iteratively call the Activity recommendation algorithm to obtain an intent test case to be sent. If the return value is empty, i.e., there is no test case for recommendation, randomly select an effective test case. If the return value is not empty, calculate the exploration time according to the size of the reachable nodes of the corresponding Activity in the Activity transition graph.

[0039] Specifically, the combination of coverage rate guidance and gray-box fuzzing test in step S8 implements feedback-based fuzzing test based on coverage guidance, including the following steps:

[0040] Step S81: Select a high-quality test case from the set of valid test cases of the recommended activity as the initial seed for this iteration, and then add it to the test case queue. If there is no qualified high-quality initial seed, randomly select a valid test case as the initial seed for fuzz testing;

[0041] Step S82: Retrieve a test sample from the test case queue and execute it, while saving its runtime information to a global data structure. During the fuzz testing process, the branch coverage information is used as the execution feedback of the current test case. If the program monitors that the current test case can enable the application to cover a new branch path, the test sample is quickly mutated according to the pre-mutation method. That is, it will treat valid test cases with different intent attribute values ​​that are pre-mutated from the same basic ICC message as the test sample as its mutated sample.

[0042] Step S83: Add the mutated sample as an input of interest to the test case queue to continue testing it;

[0043] Step S84: Repeat the above fuzzy testing process continuously. If the current execution does not generate any new feedback, the program starts the next round of recommendation exploration.

[0044] Furthermore, in step S71, the priority value is calculated as follows:

[0045]

[0046] In the above formula, eFlag represents the exploration entry flag of the Activity. If an Activity can be successfully started, it is regarded as an exploration entry and eFlag is assigned a value of 1. On the contrary, if the Activity cannot be started, its eFlag value is 0.5; mCov represents the mapping from the Activity to its method coverage, reflecting the proportion of the currently covered methods to the total number of methods. After each round of exploration, mCov will be incrementally calculated and dynamically updated; reward rNum[act] Represents the reward of the activity, where the default value of reward is 2. rNum represents the number of times the activity did not contribute to mCov after being recommended, and its initial value is 0. cConst is the program complexity constant, which is used to describe the mapping of program complexity and is calculated using the weighted entropy method. The calculation process is as follows:

[0047]

[0048] In the above formula, each activity is associated with four program complexity features, including the number of user interface controls ui, the number of call method types m, the number of statements un, and the number of branches b. The algorithm normalizes their feature values ​​and calculates the probability value P for each data. i [act], where i ranges from [1,4], corresponding to the above four features respectively; E i Represents the information entropy of different features; W i are their entropy weights; and actNum is the number of activities of the application.

[0049] Furthermore, the calculation formula of the exploration time in step S75 is as follows:

[0050]

[0051] In the above formula, node reach The number of nodes contained in the relevant subgraph of the Activity node corresponding to the test case in ATG; node all is the number of all nodes in the ATG; time is a preset value that is adjusted according to the total exploration time of the application.

[0052] Compared with the prior art, the present invention has the following beneficial effects:

[0053] 1. By adding analysis of path constraints related to additional attributes of intent, the method of the present invention can effectively extract and generate intent attribute values ​​that can enter different path conditions, thereby covering more deep code blocks and discovering more deep vulnerabilities.

[0054] 2. The method of the present invention combines the model-based testing tool APE, fully leveraging the advantages of the multi-entry testing method. By designing a dynamic Activity recommendation algorithm and introducing the coverage-guided gray-box fuzz testing concept, it can generate efficient user events and reasonably allocate exploration time. Compared with existing testing methods, it effectively improves the exploration efficiency and crash detection capabilities of the application. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the following briefly introduces the drawings required for use in the embodiments. It should be understood that the following drawings only illustrate certain embodiments of the present disclosure and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without any creative work.

[0056] Figure 1 It is a flowchart of the coverage-guided multi-entry testing method for Android applications of the present invention;

[0057] Figure 2 It is the file structure after decompilation of APK in the present invention;

[0058] Figure 3 This is the process of using the instrumentation tool to detect the Smali code of the Android application;

[0059] Figure 4 It is the layout and UI control commonly used in Android in the present invention;

[0060] Figure 5 This is the key value extraction process in the embodiment of the present invention;

[0061] Figure 6 It is the pre-mutation process in the embodiment of the present invention;

[0062] Figure 7 This is the workflow of the Activity recommendation algorithm in the embodiment of the present invention. DETAILED DESCRIPTION

[0063] In order to enable people skilled in the art to better understand the technical solutions in this specification, a real-world application Padland will be used as an example below to clearly and completely describe the technical solutions described in this specification in combination with the exemplary embodiments disclosed in this specification.

[0064] Example 1

[0065] The following example 1 shows an example related to intent reception and intent attribute manipulation, in which there is a difficult-to-find error. First, PadListActivity receives the intent passed to it by a component in the application and obtains the additional parameters "action" and "pad_id"; then the two attributes are judged. If the first condition is met, the value of the "action" attribute is checked to see if it is "delete"; if so, the corresponding records are deleted from the database one by one according to the id value in the "pad_id" attribute list, and a prompt box pops up to inform the user that the pad has been deleted; it can be noted that the "pad_id" attribute values ​​are stored in a StringArrayList type data structure, which are defined as String type, and these values ​​are parsed as Long type data in line 12; if the program does not restrict the value of the id in advance, when a string containing non-numeric characters (such as "a11") is used as an element of the "pad_id" attribute list, a NumberFormatException exception will be thrown.

[0066] Example 1

[0067]

[0068] A coverage-guided multi-entry testing system for Android applications includes a preprocessing module, a static analysis module, a fuzzy Activity startup context construction module, and a coverage-guided multi-entry exploration module; the preprocessing module is used to expose the Internal Activity of APK as ExportedActivity and perform method-level and branch-level detection on the exposed APK; the static analysis module is used to perform inter-procedural, context-sensitive, flow-sensitive, and path-sensitive analysis, and uses Jimple as the intermediate language of Soot to analyze the bytecode of the application to obtain inter-procedural control flow graph, method call graph, static Activity transition graph, and three program complexity features: number of statements, number of branches, and number of called method types; the fuzzy Activity startup context construction module uses symbolic execution, path reversal, and other methods to analyze the bytecode of the application, so as ... The Reversal and IntentFuzzing methods pre-mutate the generated ICC messages to construct effective intent test cases; the coverage-guided multi-entry exploration module combines the principles of coverage-guided gray-box fuzz testing, the designed Activity recommendation algorithm and the exploration tool APE to perform multi-entry testing on all exploration entries of the application in a targeted manner.

[0069] like Figure 1 As shown, the testing method based on the above-mentioned coverage-guided multi-entry testing system for Android applications includes the following steps:

[0070] Step S1: The preprocessing module uses the Android reverse tool APKTool to decompile the APK file and obtain the following Figure 2 The manifest file, resource file, and Smali code information shown in the figure are displayed. DOM is then used to parse the decompiled manifest file, and the component is exposed by changing the exported attribute of the Activity node. The back-compilation function provided by APKTool is continued to be used to verify the signature and repackage the file into a runnable APK.

[0071] Step S2: Figure 3 As shown in the figure, the pre-processing module uses the instrumentation tool to perform method-level and branch-level detection on the Smali code of the exposed APK to facilitate the statistical calculation of method coverage and branch coverage;

[0072] This example shows a Smali code snippet and its corresponding Java code snippet for the detected application Conversations in the dataset:

[0073] Smali code snippet for the Conversations app

[0074]

[0075] Corresponding Java code snippet

[0076]

[0077] Step S3: The static analysis module uses Jimple as the intermediate language of Soot to analyze the bytecode of the application program, and obtains the inter-procedural control flow graph, method call graph, static activity transition graph, and three program complexity features: the number of statements, the number of branches, and the number of called method types;

[0078] Step S4: The static analysis module uses the Jadx tool to obtain the source code of the APK, and then tracks the API methods related to layout view loading; after obtaining the layout file bound to the Activity, recursively traverse all resource file paths and analyze their corresponding ElementTree, such as Figure 4 The following figure shows some common layout and UI control types in Android, as well as the inheritance relationships between them. The types and quantities of common UI controls are counted based on the different label nodes in the tree to obtain the characteristic value of the number of UI controls in the Activity.

[0079] Step S5: Construct a fuzzy Activity startup context module and generate an ICC message using symbolic execution. The basic ICC message format extracted from the solution result is as follows, which mainly includes basic attributes with specific data and additional parameters including the type-key field;

[0080] ICC message format

[0081]

[0082] Step S51: Modeling intent objects according to different intent attribute types, where the intent attribute types include basic attribute types and additional parameter types; traversing the execution path of the application along the inter-procedural control flow graph, and analyzing the corresponding bytecode;

[0083] Step S52: Check whether the application uses a predefined method related to intent acquisition to obtain an intent reception variable;

[0084] Step S53: Use the def-use technique to track the usage points of these intent receiving variables and check whether the units where they are located use methods related to intent attribute acquisition to obtain the intent attribute receiving variables. For additional parameter types, it is also necessary to obtain their type-key fields.

[0085] Step S54: Continue to track the usage points of these intent attribute receiving variables, analyze the conditional expressions related to these variables and their intermediate transfer variables, and construct path constraints. The path constraints related to additional parameters will be used to analyze key values, and the path constraints related to basic attributes will be passed to the Z3 solver for attribute verification and solution, so as to prune infeasible paths and find potential attribute values ​​that meet the given constraints.

[0086] Step S55: After the constraint solution is completed, extract the basic ICC message from the solution result, which mainly includes basic attributes with specific data and additional parameters including the type-key field;

[0087] Analyze path constraints and extract key intent attribute values;

[0088] Step S56: extracting additional path constraints related to additional parameters along different execution paths;

[0089] Step S57: Invert the path constraints, construct different attribute paths, and reversely derive key values ​​that satisfy these constraints. The key values ​​associated with the basic attribute constraints are used to mutate the solved ICC message, and the key values ​​associated with the additional parameter constraints are used to fill the corresponding additional parameter fields in the ICC message.

[0090] For example, for the additional parameter "action" in Example 1, the process of extracting the key value of its intent attribute is as follows: Figure 5As shown, first extract the constraints related to it (actionStr,!=,null) and (actionStr,equals,"delete"), then negate the constraints to get three attribute paths: [(actionStr,!=,null), (actionStr,equals,"delete")], [(actionStr,!=,null),!(actionStr,equals,"delete")], [!(actionStr,!=,null)], then reversely deduce them to get the key values ​​{"delete","delete"+suffix,null}, and finally fill these values ​​as valid data into the "action" additional parameter field of the ICC message to generate a valid Activity startup context, thereby triggering deep code blocks and covering more paths;

[0091] Step S6: Pass these key values ​​to the intent fuzz test program to participate in the pre-mutation process of the ICC message, and then use rich data sources to increase the diversity of test cases and generate effective fuzzy activity startup context;

[0092] Step S61: These key values ​​are passed to the intent fuzzing program, which then compares the basic attribute values ​​of the basic ICC message with the declared data in the intent filter of the target component. If a match fails, the target component to be sent is first determined, and then the data declared in the corresponding intent filter and the key values ​​extracted from the constraints are used to mutate it, generating a set of mutated ICC messages that are closer to the expected value.

[0093] Step S62: For each ICC message, data is filled in a variety of ways according to the type and key name of the additional parameter. The data sources include key values ​​related to the additional parameter constraints, fixed values, boundary values, randomly generated strings, positive and negative values, null values, and null references.

[0094] Step S63: Generate a set of fuzzy Activity startup contexts based on the name, startup flag, and communication method of the target component;

[0095] like Figure 6The figure shows the pre-mutation process of Example 1. Since there are no constraints related to basic attributes in the ICC path corresponding to this example, the basic attribute values ​​of the basic ICC message are all null. Therefore, the basic attributes of the intent are not mutated. Next, the attribute key values ​​extracted above and diversified data from other data sources are used to mutate the basic ICC message according to the types of "action" and "pad_id" (i.e., String and StringArrayList), generating a set of mutated ICC messages (such as ICC1-4). Subsequently, the component name "padListActivity", the startup flag "true", and an explicit communication method are added to these mutated ICC messages. A set of fuzzy activity startup contexts that can reach deep code in the program can be constructed. For example, when the activity startup context corresponding to ICC2 is used as the intent test case to be sent, the program can reach the deepest location while covering as many paths as possible.

[0096] Step S7: The coverage-guided multi-entry exploration module uses static analysis results and runtime information to implement an activity recommendation algorithm, and integrates the exploration tool APE to implement a dynamic multi-entry exploration strategy;

[0097] Step S71: Calculate the priority value for each Activity component and determine the Activity with the largest priority value, i.e., maxAct;

[0098] like Figure 7 The figure shows the implementation process of the Activity recommendation algorithm, where the priority value is calculated as follows:

[0099]

[0100] In the above formula, eFlag represents the exploration entry flag of the Activity. If an Activity can be successfully started, it is regarded as an exploration entry and eFlag is assigned a value of 1. On the contrary, if the Activity cannot be started, its eFlag value is 0.5; mCov represents the mapping from the Activity to its method coverage, reflecting the proportion of the currently covered methods to the total number of methods. After each round of exploration, mCov will be incrementally calculated and dynamically updated; reward rNum[act] Represents the reward of the activity, where the default value of reward is 2. rNum represents the number of times the activity did not contribute to mCov after being recommended, and its initial value is 0. cConst is the program complexity constant, which is used to describe the mapping of program complexity and is calculated using the weighted entropy method. The calculation process is as follows:

[0101]

[0102] In the above formula, each activity is associated with four program complexity features, including the number of user interface controls ui, the number of call method types m, the number of statements un, and the number of branches b. The algorithm normalizes their feature values ​​and calculates the probability value P for each data. i [act], where i ranges from [1,4], corresponding to the above four features respectively; E i Represents the information entropy of different features; W i are their entropy weights; and actNum is the number of activities of the application;

[0103] Step S72: Determine whether maxAct is an exploration entry. If maxAct is an exploration entry, then prioritize valid intent test cases containing key values ​​and return them as recommended results. If there are no such valid test cases containing key values, then randomly select test cases from maxAct's valid test case set and return them. If maxAct is not an exploration entry, then determine whether maxAct is an isolated node. If it is an isolated node, then there can be no exploration entry in the ATG that can reach the node, so the algorithm returns an empty result. If it is not an isolated node, then calculate the distance from all exploration entries to maxAct based on the Activity transition graph, and recommend test cases for the closest Activity.

[0104] Step S73: Determine whether there are multiple results with the shortest distance. If there are multiple results, calculate the average call depth from lifecycle methods and event handling methods to intent sending methods based on the method call graph, and then recommend a test case for the activity with the shortest distance. If the result is unique, directly recommend a test case for it.

[0105] Integrate the exploration tool APE to implement a dynamic multi-entry exploration strategy;

[0106] Step S74: First, use APE to explore the main entry point of the application for a fixed time to collect initial information;

[0107] Step S75: Then, the activity recommendation algorithm is iteratively called to obtain the intent test case to be sent. If the return value is null, that is, there are no test cases for recommendation, a valid test case is randomly selected. If the return value is not null, the exploration time is calculated based on the scale of reachable nodes of the corresponding activity in the activity transition graph.

[0108] The calculation formula of the exploration time is as follows:

[0109]

[0110] In the above formula, node reach is the number of nodes contained in the relevant subgraph in the ATG for the Activity node corresponding to the test case; node all is the number of all nodes in the ATG; time is a preset value, which is adjusted according to the total exploration time length of the application program;

[0111] Step S8, in combination with the idea of coverage-guided gray-box fuzz testing, feedback-based fuzz testing based on coverage guidance is implemented;

[0112] Step S81, a high-quality test case is preferentially selected from the recommended Activity effective test case set as the initial seed of the current iteration, and then it is added to the test case queue. If there is no high-quality initial seed meeting the condition, a valid test case is randomly selected as the initial seed for fuzz testing;

[0113] Step S82, test samples are obtained from the test case queue and executed, and the runtime information thereof is saved to a global data structure. Branch coverage information is used as the execution feedback of the current test case in the process of fuzz testing. If the program monitors that the current test case can make the application program cover a new branch path, the test sample is quickly mutated according to the pre-mutation method, that is, the valid test case with different intent attribute values which is pre-mutated from the same basic ICC message together with the test sample is regarded as the mutation sample of the test sample;

[0114] Step S83, the mutation sample is added to the test case queue as the input of interest to continue testing;

[0115] Step S84, the above fuzz testing process is repeatedly performed. If the current execution does not produce any new feedback, the program starts the next round of recommended exploration;

[0116] For example, in Example 1, assume that padListActivity is recommended as an exploration entry point in a certain iteration, and the set of valid test cases related to padListActivity is {C1, C2, C3}. These intent test cases correspond to {ICC1, ICC2, ICC3} in the ICC message format, respectively. It can be observed that the "action" attribute of ICC1 and ICC2 has the key value "delete," thus screening C1 and C2 as high-quality test cases. Assuming C1 is selected as the initial seed for fuzz testing, and new branch coverage feedback is successfully generated after acquiring and executing this sample, then the valid test cases C2 and C3, which were pre-mutated from the same basic ICC message as C1, are considered as its mutated samples and added to the test case queue as interesting test cases for further testing. This approach enables rapid seed mutation without rebuilding the auxiliary application, thereby guiding the program into different branch paths.

[0117] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any other manner. Any person skilled in the art may utilize the above-disclosed technical content to modify or modify the present invention into equivalent embodiments. However, any simple modifications, equivalent variations, and modifications to the above embodiments that do not depart from the technical content of the present invention and are based on the technical essence of the present invention remain within the scope of protection of the present invention.

Claims

1. A coverage-guided multi-entry testing system for Android applications, characterized by: The system includes a preprocessing module, a static analysis module, a module for building fuzzy activity startup contexts, and a coverage-guided multi-entry exploration module. The preprocessing module is used to expose the APK's internal activities as exported activities and perform method-level and branch-level inspections on the exposed APKs. The static analysis module is used to perform inter-procedural, context-sensitive, flow-sensitive, and path-sensitive analysis. Jimple is used as Soot's intermediate language to analyze the application's bytecode to obtain inter-procedural control flow graphs, method call graphs, static activity transition graphs, and three program complexity features: the number of statements, the number of branches, and the number of called method types. The module for building a fuzzy Activity startup context uses symbolic execution, path reversal, and intent fuzzing methods to pre-mutate the generated ICC message to build a valid intent test case. The coverage-guided multi-entry exploration module combines the principle of coverage-guided gray-box fuzz testing, the designed Activity recommendation algorithm and the exploration tool APE to perform multi-entry testing on all exploration entries of the application in a targeted manner.

2. A test method for a coverage-guided multi-entry test system for Android applications as claimed in claim 1, characterized in that: The following steps are involved: Step S1: The preprocessing module uses the Android reverse engineering tool APKTool to decompile the APK file to obtain the manifest file, resource files, and Smali code information; then uses DOM to parse the decompiled manifest file and expose the component by changing the exported attribute of the Activity node; then uses the back compilation function provided by APKTool to perform signature verification and repackage the file into an executable APK; Step S2: The pre-processing module uses the instrumentation tool to perform method-level and branch-level detection on the Smali code of the exposed APK to facilitate the statistical calculation of method coverage and branch coverage; Step S3: The static analysis module uses Jimple as the intermediate language of Soot to analyze the bytecode of the application program, and obtains the inter-procedural control flow graph, method call graph, static activity transition graph, and three program complexity features: the number of statements, the number of branches, and the number of called method types; Step S4: The static analysis module uses the Jadx tool to obtain the source code of the APK and then traces the API methods related to layout view loading. After obtaining the layout file bound to the Activity, it recursively traverses all resource file paths and analyzes their corresponding ElementTrees. Based on the different label nodes in the tree, the types and numbers of common UI controls are counted to obtain the characteristic value of the number of UI controls in the Activity. Step S5: Construct a fuzzy Activity startup context module and generate ICC messages using symbolic execution; analyze the path constraints and extract key intent attribute values; Step S6: Pass these key values ​​to the intent fuzz test program to participate in the pre-mutation process of the ICC message, and then use rich data sources to increase the diversity of test cases and generate effective fuzzy activity startup context; Step S7: The coverage-guided multi-entry exploration module uses static analysis results and runtime information to implement an activity recommendation algorithm, and integrates the exploration tool APE to implement a dynamic multi-entry exploration strategy; Step S8: Combine the coverage-guided grey-box fuzz testing concept to implement coverage-guided fuzz testing with feedback.

3. The coverage-guided multi-entry testing method for Android applications according to claim 2, characterized in that: The construction of the fuzzy Activity startup context module in step S5 generates an ICC message using symbolic execution, including the following steps: Step S51: Modeling intent objects according to different intent attribute types, where the intent attribute types include basic attribute types and additional parameter types; traversing the execution path of the application along the inter-procedural control flow graph, and analyzing the corresponding bytecode; Step S52: Check whether the application uses a predefined method related to intent acquisition to obtain an intent reception variable; Step S53: Use the def-use technique to track the usage points of these intent receiving variables and check whether the units where they are located use methods related to intent attribute acquisition to obtain the intent attribute receiving variables. For additional parameter types, it is also necessary to obtain their type-key fields. Step S54: Continue to track the usage points of these intent attribute receiving variables, analyze the conditional expressions related to these variables and their intermediate transfer variables, and construct path constraints. The path constraints related to additional parameters will be used to analyze key values, and the path constraints related to basic attributes will be passed to the Z3 solver for attribute verification and solution, so as to prune infeasible paths and find potential attribute values ​​that meet the given constraints. Step S55: After the constraint solution is completed, the basic ICC message is extracted from the solution result, which mainly includes basic attributes with specific data and additional parameters including the type-key field.

4. The coverage-guided multi-entry testing method for Android applications according to claim 2, characterized in that: Analyzing the path constraints and extracting key intent attribute values ​​in step S5 includes the following steps: Step S56: extracting additional path constraints related to additional parameters along different execution paths; Step S57: Invert the path constraints, construct different attribute paths, and reversely deduce the key values ​​that satisfy these constraints, where the key values ​​related to the basic attribute constraints are used to mutate the solved ICC message, and the key values ​​related to the additional parameter constraints are used to fill the corresponding additional parameter fields in the ICC message.

5. The coverage-guided multi-entry testing method for Android applications according to claim 2, characterized in that: The process of generating a valid fuzzy Activity startup context in step S6 is as follows: Step S61: These key values ​​are passed to the intent fuzzing program, which then compares the basic attribute values ​​of the basic ICC message with the declared data in the intent filter of the target component. If a match fails, the target component to be sent is first determined, and then the data declared in the corresponding intent filter and the key values ​​extracted from the constraints are used to mutate it, generating a set of mutated ICC messages that are closer to the expected value. Step S62: For each ICC message, data is filled in a variety of ways according to the type and key name of the additional parameter. The data sources include key values ​​related to the additional parameter constraints, fixed values, boundary values, randomly generated strings, positive and negative values, null values, and null references. Step S63: Generate a set of fuzzy Activity startup contexts based on the name, startup flag, and communication method of the target component.

6. The coverage-guided multi-entry testing method for Android applications according to claim 2, characterized in that: The coverage-guided multi-entry exploration module in step S7 implements an activity recommendation algorithm using static analysis results and runtime information, including the following steps: Step S71: Calculate the priority value for each Activity component and determine the Activity with the largest priority value, i.e., maxAct; Step S72: Determine whether maxAct is an exploration entry. If maxAct is an exploration entry, then prioritize valid intent test cases containing key values ​​and return them as recommended results. If there are no such valid test cases containing key values, then randomly select test cases from maxAct's valid test case set and return them. If maxAct is not an exploration entry, then determine whether maxAct is an isolated node. If it is an isolated node, then there can be no exploration entry in the ATG that can reach the node, so the algorithm returns an empty result. If it is not an isolated node, then calculate the distance from all exploration entries to maxAct based on the Activity transition graph, and recommend test cases for the closest Activity. Step S73: Determine whether there are multiple results with the shortest distance. If there are multiple results, calculate the average call depth from the lifecycle method and event handling method to the intent sending method based on the method call graph, and then recommend a test case for the activity with the shortest distance. If the result is unique, directly recommend a test case for it.

7. The coverage-guided multi-entry testing method for Android applications according to claim 2, characterized in that: The integrated exploration tool APE in step S7 implements a dynamic multi-entry exploration strategy, including the following steps: Step S74: First, use APE to explore the main entry point of the application for a fixed time to collect initial information; Step S75: Then iteratively call the Activity recommendation algorithm to obtain the intent test case to be sent. If the return value is empty, that is, there is no test case for recommendation, then randomly select a valid test case. If the return value is not empty, the exploration time is calculated based on the scale of the reachable nodes of its corresponding Activity in the Activity transition graph.

8. The coverage-guided multi-entry testing method for Android applications according to claim 2, characterized in that: The step S8 combines the coverage-guided grey-box fuzz testing concept to implement coverage-guided fuzz testing with feedback, including the following steps: Step S81: Select a high-quality test case from the set of valid test cases of the recommended activity as the initial seed for this iteration, and then add it to the test case queue. If there is no qualified high-quality initial seed, randomly select a valid test case as the initial seed for fuzz testing; Step S82: Retrieve a test sample from the test case queue and execute it, while saving its runtime information to a global data structure. During the fuzz testing process, the branch coverage information is used as the execution feedback of the current test case. If the program monitors that the current test case can enable the application to cover a new branch path, the test sample is quickly mutated according to the pre-mutation method. That is, it will treat valid test cases with different intent attribute values ​​that are pre-mutated from the same basic ICC message as the test sample as its mutated sample. Step S83: Add the mutated sample as an input of interest to the test case queue to continue testing it; Step S84: Repeat the above fuzzy testing process continuously. If the current execution does not generate any new feedback, the program starts the next round of recommendation exploration.

9. The coverage-guided multi-entry testing method for Android applications according to claim 6, characterized in that: In step S71, the priority value is calculated as follows: In the above formula, eFlag represents the exploration entry flag of the Activity. If an Activity can be successfully started, it is regarded as an exploration entry and eFlag is assigned a value of 1. On the contrary, if the Activity cannot be started, its eFlag value is 0.5; mCov represents the mapping from the Activity to its method coverage, reflecting the proportion of the currently covered methods to the total number of methods. After each round of exploration, mCov will be incrementally calculated and dynamically updated; reward rNum[act] Represents the reward of the activity, where the default value of reward is 2. rNum represents the number of times the activity did not contribute to mCov after being recommended, and its initial value is 0. cConst is the program complexity constant, which is used to describe the mapping of program complexity and is calculated using the weighted entropy method. The calculation process is as follows: In the above formula, each activity is associated with four program complexity features, including the number of user interface controls ui, the number of call method types m, the number of statements un, and the number of branches b. The algorithm normalizes their feature values ​​and calculates the probability value P for each data. i [act], where i ranges from 1 to 4, corresponding to the four features mentioned above; E i Information entropy representing different features; W i are their entropy weights; and actNum is the number of activities of the application.

10. The coverage-guided multi-entry testing method for Android applications according to claim 7, characterized in that: The calculation formula for the exploration time in step S75 is as follows: In the above formula, node reach The number of nodes contained in the relevant subgraph of the Activity node corresponding to the test case in ATG; node all is the number of all nodes in the ATG; time is a preset value that is adjusted according to the total exploration time of the application.

Images