A method for detecting counterfeit Android applications based on interface layout

Abstract

The present invention relates to an Android counterfeit application detection method based on interface layout. Based on the running interfaces of each Activity in a genuine Android application and an Android application to be tested, an interface structure feature vector of the interface layout and a type feature vector corresponding to each type of preset feature are extracted; and according to the interface structure feature vector and a screenshot of the interface, each Activity group to be analyzed is screened out, and then the similarity corresponding to each Activity group to be analyzed is calculated through the type feature vector corresponding to each type of preset feature; finally, based on the similarity between the genuine Android application and the Android application to be tested, whether the Android application to be tested is a counterfeit application is judged; compared with the current mainstream counterfeit APP detection algorithm, the main advantage of this method is that it has strong anti-obfuscation ability and high execution efficiency, and can effectively detect different types of application counterfeiting, and can not only detect traditional application counterfeiting behaviors, but also effectively detect more complex and more targeted application interface counterfeiting.

Description

Technical Field

[0001] The invention relates to an Android counterfeit application detection method based on interface layout, belonging to the technical field of mobile terminal security and counterfeit identification. Background Art

[0002] As the mobile market has gradually emerged in recent years, Android, as a mainstream mobile operating system, has also been booming. According to data from StatCounter, a data analysis agency, Android's market share has been growing steadily year by year since its release. As of 2020, Android has occupied 74.3% of the global mobile market share. At the same time, the number of Android applications has also been rising with the booming Android market. In 2017, the official Android app store Google Play alone launched nearly one million new applications for download. Although the number of applications on Google Play has fallen back in 2018 for various reasons, there are still nearly three million available applications on the app market, and the Android app market is still vibrant.

[0003] With the rapid development of the Android mobile application industry, mobile black and gray industries (i.e., mobile black and gray industries, the same below) have also become increasingly active. Black and gray industries are industries that make profits by infringing on the interests of users, original application authors, or other third parties or through other suspicious means. On the one hand, as the threshold for developing mobile applications gradually decreases, the cost of developing a mobile application is generally lower than the cost of developing a similar desktop application; on the other hand, the flexibility of mobile application functions in implementation has increased the complexity of mobile applications, and the analysis and interception of black and gray industries face a variety of new challenges. The combination of these two aspects provides a good foundation for the development of black and gray applications into mobile terminals.

[0004] Counterfeit applications are a type of widespread mobile gray and black products. Counterfeit applications are software that counterfeiters use the same original application data or application metadata as genuine applications to induce users to download, such as similar logos, similar names, similar UI interfaces and content, so as to confuse users. Counterfeit application developers mostly imitate applications with large download volumes and relatively popular applications in app stores to make profits. Once users download such counterfeit applications, their built-in malicious behaviors will appear, such as: spreading illegal and illegal information such as violence, terrorism, pornography, etc.; stealing user privacy information, using paid services without authorization, maliciously pushing advertisements, etc., directly damaging the actual interests of users and threatening the security of user privacy information.

[0005] Most of the existing research on application counterfeit fraud detection focuses on the problem of application repackaging, and achieves fraud detection by extracting and comparing static features of applications. Some scholars have achieved counterfeit fraud detection based on interface content similarity. However, in recent years, counterfeit fraud detection countermeasures have been continuously upgraded, and some experienced malicious developers have deliberately modified interface content and function codes to evade detection. In particular, there are the following problems: counterfeit applications need to maintain the similarity of the interface with the original application to deceive users. Under the premise of minimal impact on the program's dynamic display interface, the interface content features are very easy to be modified by malicious developers, while the interface structure features remain relatively stable.

[0006] Therefore, with the formation and improvement of the mobile application ecosystem, traditional fraud has migrated to the mobile Internet and adopted new fraud methods. The endless emergence of new frauds has not only caused great damage to the ecosystem, but also brought severe challenges to the application market and regulatory authorities. Fraud detection and countermeasures technology is constantly upgraded. Experienced malicious developers circumvent existing detection methods by upgrading fraud technology. Existing technologies and means can no longer effectively detect more targeted new frauds. Summary of the invention

[0007] The technical problem to be solved by the present invention is to provide an Android counterfeit application detection method based on interface layout, which adopts a new detection and comparison design and can effectively improve the accuracy and efficiency of counterfeit application detection.

[0008] In order to solve the above technical problems, the present invention adopts the following technical solutions: The present invention designs an Android counterfeit application detection method based on interface layout, based on the genuine Android application, the corresponding Android application to be tested is detected, including the following steps:

[0009] Step A. Obtain screenshots of each Activity running interface in the Android application and layout information of each Activity running interface for the genuine Android application and the Android application to be tested, and then proceed to step B;

[0010] Step B. For each Activity running interface in the genuine Android application and the Android application to be tested, according to the layout information of the Activity running interface, obtain the interface structure feature vector corresponding to the Activity running interface and the type feature vector corresponding to each type of preset feature of the Activity running interface, and then proceed to step C;

[0011] Step C. constructing a pairwise combination of each Activity running interface in the genuine Android application and each Activity running interface in the tested Android application as each Activity group, and screening each Activity group according to the interface structure feature vector corresponding to each Activity running interface and the screenshot of each Activity running interface, and the obtained Activity groups are used as each Activity group to be analyzed, and then proceeding to step D;

[0012] Step D. According to the type feature vectors of the preset types of features corresponding to the running interfaces of each Activity in the genuine Android application and the Android application to be tested, for each Activity group to be analyzed, the feature similarity of the preset types of features corresponding to the Activity group to be analyzed is obtained, and then the feature similarity of the preset types of features corresponding to the Activity group to be analyzed is obtained, and then the process proceeds to step E;

[0013] Step E. For each Activity group to be analyzed, for each judgment condition that the feature similarity of each type of feature preset in the Activity group to be analyzed is not less than the feature similarity threshold of the corresponding type, if at least one judgment condition is met, the similarity corresponding to the Activity group to be analyzed is defined as 1; if all judgment conditions are not met, the similarity corresponding to the Activity group to be analyzed is defined as 0; then the similarities corresponding to each Activity group to be analyzed are obtained, and then step F is entered;

[0014] Step F. Obtain the sum of similarities G corresponding to each Activity group to be analyzed, and then use the following formula:

[0015]

[0016] The similarity SIMAPP between the genuine Android application and the Android application to be tested is obtained, and it is determined whether the similarity SIMAPP is greater than a preset application similarity threshold. If so, the Android application to be tested is determined to be a counterfeit application, otherwise, the Android application to be tested is determined to be a non-counterfeit application; wherein U and V represent the number of Activity running interfaces in the genuine Android application and the number of Activity running interfaces in the Android application to be tested, respectively.

[0017] As a preferred technical solution of the present invention: in the step A, for the genuine Android application and the Android application to be tested, the following steps A1 to A3 are executed respectively to obtain screenshots of each Activity running interface in the Android application and layout information of each Activity running interface, and then proceed to step B;

[0018] Step A1. Use ApkTool to decompress and decompile the APK of the Android application, obtain the compilation result corresponding to the Android application, and proceed to step A2;

[0019] Step A2. Filter out the third-party library Activities registered in AndroidManifest.xml in the compilation result, and add intent-filter nodes, action subnodes, and category subnodes to the remaining Activities in the compilation result, and then package the compilation result to form an APK to be processed, and then proceed to step A3;

[0020] Step A3. Install the APK to be processed based on the Android simulator, start each Activity in the APK to be processed by Appium, call the getScreenshotAs() function provided by Appium, obtain the screenshot of each Activity running interface on the Android simulator, and call the getPageSource() function provided by Appium to obtain the layout information of each Activity running interface on the Android simulator.

[0021] As a preferred technical solution of the present invention: in the step B, for each Activity running interface in the genuine Android application and the Android application to be tested, the following steps B1 to B4 are executed to obtain the interface structure feature vector corresponding to the Activity running interface and the preset feature vectors of each type, and then proceed to step C;

[0022] Step B1. According to the layout information of the Activity running interface, traverse each control in the layout information in turn, extract the upper and lower bounds of the vertical coordinate from the bounds attribute of the control, construct each layer and each control contained in each layer, and then combine each layer to form a layer set corresponding to the Activity running interface, and then enter step B2;

[0023] Step B2. For the layer set corresponding to the Activity running interface, each independent layer is obtained by merging adjacent layers containing the same control type and the same number of controls to form an independent layer, and the overlapping layer attribute of each independent layer is set to true. The remaining layers are directly used as independent layers, and the overlapping layer attribute of each independent layer is set to false. Then, the independent layers are combined to form the independent layer set corresponding to the Activity running interface, and then the process proceeds to step B3;

[0024] Step B3. The number of layers in the layer set corresponding to the Activity running interface, the number of independent layers in the corresponding independent layer set, and the number of independent layers with overlapping layer attributes of true in the corresponding independent layer set are combined to form the interface structure feature vector corresponding to the Activity running interface, and then proceed to step B4;

[0025] Step B4: traverse each independent layer in the independent layer set corresponding to the Activity running interface, and obtain the type feature vectors corresponding to each type of preset feature of the Activity running interface.

[0026] As a preferred technical solution of the present invention: the step B1 includes the following steps B1-1 to B1-4;

[0027] Step B1-1. Initialize l=1, k=1, and proceed to step B1-2;

[0028] Step B1-2. According to the layout information of the Activity running interface, traverse the lth control in the layout information, extract the upper and lower bounds of the ordinate from the bounds attribute of the control as the upper and lower bounds corresponding to the lth control, and proceed to step B1-3;

[0029] Step B1-3. If l=1, the upper and lower bounds corresponding to the lth control are used as the upper and lower bounds of the kth layer, and the lth control is added to the kth layer, and then the process proceeds to step B1-4;

[0030] If l>1, determine whether the upper and lower bounds corresponding to the lth control are contained in the upper and lower bounds of the kth layer. If so, add the lth control to the kth layer and proceed to step B1-4; otherwise, use the upper and lower bounds corresponding to the lth control as the upper and lower bounds of the k+1th layer, add the lth control to the k+1th layer, then add 1 to the value of k and proceed to step B1-4;

[0031] Step B1-4. Determine whether l is equal to the number L of controls in the layout information of the Activity running interface. If so, the layer set corresponding to the Activity running interface is composed of each layer and each control contained in each layer; otherwise, update the value of l by adding 1 and return to step B1-2.

[0032] As a preferred technical solution of the present invention: the step C includes the following steps C1 to C3;

[0033] Step C1. Constructing pairs of Activity running interfaces in the genuine Android application and Activity running interfaces in the tested Android application as Activity groups, and proceeding to step C2;

[0034] Step C2. For each Activity group, obtain the absolute value a of the difference in the number of layers in the layer set corresponding to the two Activity running interfaces in the Activity group, and obtain the absolute value b of the difference in the number of independent layers with the overlapping layer attribute of true in the independent layer set corresponding to the two Activity running interfaces in the Activity group, and then determine whether a is greater than a preset first threshold or b is greater than a preset second threshold. If so, delete the Activity group, otherwise define the Activity group as a primary Activity group; then enter step C3;

[0035] Step C3. For each preliminary Activity group, apply the LMGist algorithm to obtain the spatial envelope feature vector of the screenshots of the two Activity running interfaces of the preliminary Activity group, and calculate the cosine similarity distance between the two spatial envelope feature vectors to determine whether the cosine similarity distance is greater than a preset third threshold. If so, define the preliminary Activity group as the Activity group to be analyzed, otherwise delete the preliminary Activity group.

[0036] As a preferred technical solution of the present invention: in the step D, according to the type feature vectors of the preset types of features respectively corresponding to the running interfaces of each Activity in the genuine Android application and the Android application to be tested, for each Activity group to be analyzed, the following operations are performed to obtain the feature similarity of the preset types of features respectively corresponding to the Activity group to be analyzed, and then obtain the feature similarity of the preset types of features respectively corresponding to the Activity group to be analyzed, and then enter step E;

[0037] Operation: For each preset type feature, the type feature vector f corresponding to the type feature of the two Activity running interfaces in the Activity group to be analyzed is A 、f B , according to the following formula:

[0038]

[0039] Get the feature similarity SIM(f A , f B ), where I represents the type feature vector f of one of the Activity running interfaces in the Activity group to be analyzed corresponding to the type feature A The number of feature elements in , J represents the type feature vector f of another Activity running interface in the Activity group to be analyzed corresponding to the type feature B The number of characteristic elements in C A，i The type feature vector f that represents the type feature corresponding to one of the Activity running interfaces in the Activity group to be analyzed A The i-th characteristic element in C B，j The type feature vector f that represents the type feature of another Activity running interface in the Activity group to be analyzed B The jth characteristic element in , and SIM(C A，i , C B，j ) is calculated as follows:

[0040]

[0041] Then, the feature similarities of the preset features of each type corresponding to the Activity group to be analyzed are obtained.

[0042] As a preferred technical solution of the present invention: the preset feature vectors of various types include text feature vectors. In the step B4, each independent layer in the independent layer set corresponding to the Activity running interface is traversed, and the text of the text or content-desc of each control contained in the independent layer is saved in the text feature set corresponding to the independent layer, and then the text feature sets corresponding to each independent layer are obtained, and the text feature vector corresponding to the Activity running interface is composed of each text feature set.

[0043] As a preferred technical solution of the present invention: the preset feature vectors of each type include a control type feature vector. In the step B4, each independent layer in the independent layer set corresponding to the Activity running interface is traversed, and the text of the class attribute of each control contained in the independent layer is saved in the control type feature set corresponding to the independent layer, and then the control type feature sets corresponding to each independent layer are obtained, and the control type feature vector corresponding to the Activity running interface is composed of each control type feature set.

[0044] As a preferred technical solution of the present invention: the preset feature vectors of various types include control ID feature vectors. In the step B4, each independent layer in the independent layer set corresponding to the Activity running interface is traversed, and the text of the resource-id attribute of each control contained in the independent layer is saved in the control ID feature set corresponding to the independent layer, and then the control ID feature sets corresponding to each independent layer are obtained, and the control ID feature vector corresponding to the Activity running interface is composed of each control ID feature set.

[0045] The Android counterfeit application detection method based on interface layout described in the present invention adopts the above technical solution and has the following technical effects compared with the prior art:

[0046] The present invention designs an Android counterfeit application detection method based on interface layout. First, screenshots of each Activity running interface in the genuine Android application and the Android application to be tested, as well as layout information of each Activity running interface are obtained; then, the layout information of each Activity running interface is preprocessed, and the interface structure feature vector, text feature vector, control type feature vector and control ID feature vector of its interface layout are extracted; each Activity group to be analyzed that is similar between the genuine application and the application to be tested is screened out through the interface structure feature vector and the interface screenshot, and then the similarity corresponding to each Activity group to be analyzed is calculated through the text feature vector, the control type feature vector and the control ID feature vector; finally, the similarity SIMAPP between the genuine Android application and the Android application to be tested is calculated based on the similarity between the Activity running interfaces, and whether the Android application to be tested is a counterfeit application is determined according to the calculation result; compared with the current mainstream counterfeit APP detection algorithm, the main advantage of this method is that it has strong anti-obfuscation ability, high execution efficiency, can effectively detect different types of application counterfeiting, can not only detect traditional application counterfeiting behavior, but also can effectively detect more complex and more targeted application interface counterfeiting. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Figure 1 It is a flow chart of the Android counterfeit application detection method based on interface layout designed by the present invention. DETAILED DESCRIPTION

[0048] The specific implementation modes of the present invention will be further described in detail below in conjunction with the accompanying drawings.

[0049] The present invention designs an Android counterfeit application detection method based on interface layout, based on genuine Android applications, to detect the corresponding Android applications to be tested. In actual application, Figure 1 As shown, specifically perform the following steps A to step.

[0050] Step A: For the genuine Android application and the Android application to be tested, respectively, obtain screenshots of each Activity running interface in the Android application and layout information of each Activity running interface, and then proceed to step B.

[0051] In actual application, in the above step A, for the genuine Android application and the Android application to be tested, respectively, the following steps A1 to A3 are executed to obtain screenshots of each Activity running interface in the Android application and layout information of each Activity running interface, and then proceed to step B.

[0052] Step A1. Use ApkTool to decompress and decompile the APK of the Android application, obtain the compilation result corresponding to the Android application, and proceed to step A2.

[0053] Step A2: Filter out the third-party library Activities registered in AndroidManifest.xml in the compilation result, and add intent-filter nodes, action subnodes, and category subnodes to the remaining Activities in the compilation result. Then, package the compilation result to form an APK to be processed, and then proceed to step A3.

[0054] Step A3. Install the APK to be processed based on the Android simulator, start each Activity in the APK to be processed by Appium, call the getScreenshotAs() function provided by Appium, obtain the screenshot of each Activity running interface on the Android simulator, and call the getPageSource() function provided by Appium to obtain the layout information of each Activity running interface on the Android simulator.

[0055] It was found in the application that the existing automated testing tools are inefficient and not suitable for large-scale counterfeit fraud detection application scenarios. It takes several hours on average to completely traverse all interfaces in an application. Since the Activity component needs to be declared in the AndroidManifest.xml file in the application to be successfully started. Therefore, by decompiling the APK, analyzing the Activity registered in AndroidManifest.xml, and adding the android.intent.category.launcher attribute to the Activity component, the Activity can be directly started by the automated tool. This saves the analysis time such as searching for interface entry points when traversing the application by traditional automated tools. This method is much less complex and time-consuming, and achieves a balance between UI coverage and automated testing performance.

[0056] In the specific implementation, due to the application of the design method of the present invention, the Activity component of each application needs to have the "android.intent.category.launcher" tag, so the original application needs to be preprocessed, and the application is decompiled by using the reverse tool Apktool, and the AndroidManifest.xml file in the application is modified. Considering the impact of third-party libraries on the detection results, the relevant Activity components are filtered out according to the public third-party library whitelist. For each declared Activity, add the intent-filter node and its action and category child nodes, then repackage it with Apktool and re-sign it with Signapk to generate a new executable application.

[0057] Step B. For each Activity running interface in the genuine Android application and the Android application to be tested, according to the layout information of the Activity running interface, obtain the interface structure feature vector corresponding to the Activity running interface and the type feature vector corresponding to each type of preset feature of the Activity running interface, and then enter step C.

[0058] In actual applications, in the above step B, for each Activity running interface in the genuine Android application and the Android application to be tested, execute the following steps B1 to B4 to obtain the interface structure feature vector corresponding to the Activity running interface and the preset feature vectors of each type, and then enter step C.

[0059] Step B1. According to the layout information of the Activity running interface, traverse each control in the layout information in turn, and construct each layer and each control contained in each layer by extracting the upper and lower bounds of the vertical coordinate from the bounds attribute of the control. Then, each layer is combined to form a layer set corresponding to the Activity running interface, and then enter step B2.

[0060] The above step B1 is specifically implemented by steps B1-1 to B1-4.

[0061] Step B1-1. Initialize l=1, k=1, and proceed to step B1-2.

[0062] Step B1-2. According to the layout information of the Activity running interface, traverse the lth control in the layout information, extract the upper and lower bounds of the vertical coordinate from the bounds attribute of the control as the upper and lower bounds corresponding to the lth control, and enter step B1-3.

[0063] Step B1-3. If l=1, the upper and lower bounds corresponding to the lth control are used as the upper and lower bounds of the kth layer, and the lth control is added to the kth layer, and then the process goes to step B1-4.

[0064] If l>1, determine whether the upper and lower bounds corresponding to the lth control are contained in the upper and lower bounds of the kth layer. If so, add the lth control to the kth layer and go to step B1-4; otherwise, use the upper and lower bounds corresponding to the lth control as the upper and lower bounds of the k+1th layer, add the lth control to the k+1th layer, then update the value of k by adding 1, and then go to step B1-4.

[0065] Step B1-4. Determine whether l is equal to the number L of controls in the layout information of the Activity running interface. If so, the layer set corresponding to the Activity running interface is composed of each layer and each control contained in each layer; otherwise, update the value of l by adding 1 and return to step B1-2.

[0066] Step B2. For the layer set corresponding to the Activity running interface, each independent layer is obtained by merging adjacent layers containing the same control type and the same number of controls to form an independent layer, and the overlapping layer attribute of each independent layer is set to true. The remaining layers are directly used as independent layers, and the overlapping layer attribute of each independent layer is set to false. Then, the independent layer set corresponding to the Activity running interface is composed of various independent layers, and then step B3 is entered.

[0067] Step B3. The interface structure feature vector corresponding to the Activity running interface is composed of the number of layers in the layer set corresponding to the Activity running interface, the number of independent layers in the corresponding independent layer set, and the number of independent layers with overlapping layer attributes of true in the corresponding independent layer set, and then proceed to step B4.

[0068] Step B4: traverse each independent layer in the independent layer set corresponding to the Activity running interface, and obtain the type feature vectors corresponding to each type of preset feature of the Activity running interface.

[0069] Comparing Activity running interfaces pairwise is very time-consuming. Since most applications contain no less than 10 Activities and the number of layers in an Activity is no less than 5, this will result in more than 2,500 feature comparisons of Activity running interfaces between applications. In addition, the visual effects of many application Activity running interfaces vary greatly, and comparing these Activity running interfaces is meaningless. Through observation, it is found that two Activity running interfaces with very different visual effects are mainly manifested in two aspects in terms of hierarchical features: (1) the number of layers varies greatly; (2) the number of overlapping layers varies greatly. Therefore, a method based on hierarchical feature priority comparison is used. If the hierarchical features of two Activity running interfaces vary greatly, they are deemed to be dissimilar and there is no need to further compare other features. That is, continue to execute the following step C.

[0070] Step C. construct a pairwise combination of each Activity running interface in the genuine Android application and each Activity running interface in the Android application to be tested as each Activity group, and screen each Activity group according to the interface structure feature vector corresponding to each Activity running interface and the screenshot of each Activity running interface, and the obtained Activity groups are used as each Activity group to be analyzed, and then enter step D.

[0071] In practical applications, the above step C specifically performs the following steps C1 to C3.

[0072] Step C1. Construct pairs of Activity running interfaces in the genuine Android application and Activity running interfaces in the Android application to be tested as Activity groups, and proceed to step C2.

[0073] Step C2. For each Activity group, obtain the absolute value a of the difference in the number of layers in the layer set corresponding to the two Activity running interfaces in the Activity group, and obtain the absolute value b of the difference in the number of independent layers with an overlapping layer attribute of true in the independent layer set corresponding to the two Activity running interfaces in the Activity group, and then determine whether a is greater than a preset first threshold or b is greater than a preset second threshold. If so, delete the Activity group; otherwise, define the Activity group as a primary Activity group; then go to step C3.

[0074] Step C3. For each preliminary Activity group, apply the LMGist algorithm to obtain the spatial envelope feature vector of the screenshots of the two Activity running interfaces of the preliminary Activity group, and calculate the cosine similarity distance between the two spatial envelope feature vectors to determine whether the cosine similarity distance is greater than a preset third threshold. If so, define the preliminary Activity group as the Activity group to be analyzed, otherwise delete the preliminary Activity group.

[0075] Step D. According to the type feature vectors of each type of features preset in the running interface of each Activity in the genuine Android application and the Android application to be tested, for each Activity group to be analyzed, obtain the feature similarity of each type of features preset in the Activity group to be analyzed, and then obtain the feature similarity of each type of features preset in the Activity group to be analyzed, and then enter step E.

[0076] In actual applications, in the above step D, according to the type feature vectors of each type of features preset corresponding to each Activity running interface in the genuine Android application and the Android application to be tested, the following operations are performed for each Activity group to be analyzed, to obtain the feature similarity of each type of features preset corresponding to the Activity group to be analyzed, and then obtain the feature similarity of each type of features preset corresponding to each Activity group to be analyzed, and then enter step E.

[0077] Operation: For each preset type feature, the type feature vector f corresponding to the type feature of the two Activity running interfaces in the Activity group to be analyzed is A 、f B , according to the following formula:

[0078]

[0079] Get the feature similarity SIM(f A , f B ), where I represents the type feature vector f of one of the Activity running interfaces in the Activity group to be analyzed corresponding to the type feature A The number of feature elements in , J represents the type feature vector f of another Activity running interface in the Activity group to be analyzed corresponding to the type feature B The number of characteristic elements in C A,i The type feature vector f that represents the type feature corresponding to one of the Activity running interfaces in the Activity group to be analyzed A The i-th characteristic element in C B,j The type feature vector f that represents the type feature of another Activity running interface in the Activity group to be analyzed B The jth characteristic element in , and Calculated as follows:

[0080]

[0081] Then, the feature similarities of the preset features of each type corresponding to the Activity group to be analyzed are obtained.

[0082] Specifically, in the above step D, the preset feature vectors of various types include text feature vectors, control type feature vectors, and control ID feature vectors. For the text feature vectors, in the step B4, each independent layer in the independent layer set corresponding to the Activity running interface is traversed, and the text of the text or content-desc of each control contained in the independent layer is saved in the text feature set corresponding to the independent layer, and then the text feature sets corresponding to each independent layer are obtained, and the text feature vector corresponding to the Activity running interface is composed of each text feature set.

[0083] For the control type feature vector, in step B4, each independent layer in the independent layer set corresponding to the Activity running interface is traversed, and the text of the class attribute of each control contained in the independent layer is saved in the control type feature set corresponding to the independent layer, and then the control type feature sets corresponding to each independent layer are obtained, and the control type feature vector corresponding to the Activity running interface is composed of each control type feature set.

[0084] For the control ID feature vector, in step B4, each independent layer in the independent layer set corresponding to the Activity running interface is traversed, and the text of the resource-id attribute of each control contained in the independent layer is saved in the control ID feature set corresponding to the independent layer, and then the control ID feature sets corresponding to each independent layer are obtained, and the control ID feature vector corresponding to the Activity running interface is composed of each control ID feature set.

[0085] Step E. For each Activity group to be analyzed, for each judgment condition that the feature similarity of each type of feature preset in the Activity group to be analyzed is not less than the corresponding type feature similarity threshold, if at least one judgment condition is met, the similarity corresponding to the Activity group to be analyzed is defined as 1; if all judgment conditions are not met, the similarity corresponding to the Activity group to be analyzed is defined as 0; then the similarities corresponding to each Activity group to be analyzed are obtained, and then step F is entered.

[0086] Step F. Obtain the sum of similarities G corresponding to each Activity group to be analyzed, and then use the following formula:

[0087]

[0088] The similarity SIMAPP between the genuine Android application and the Android application to be tested is obtained, and it is determined whether the similarity SIMAPP is greater than a preset application similarity threshold. If so, the Android application to be tested is determined to be a counterfeit application, otherwise, the Android application to be tested is determined to be a non-counterfeit application; wherein U and V represent the number of Activity running interfaces in the genuine Android application and the number of Activity running interfaces in the Android application to be tested, respectively.

[0089] The above technical solution designs an Android counterfeit application detection method based on interface layout. First, screenshots of each Activity running interface in the genuine Android application and the Android application to be tested, as well as layout information of each Activity running interface, are obtained; then, the layout information of each Activity running interface is preprocessed, and the interface structure feature vector, text feature vector, control type feature vector and control ID feature vector of its interface layout are extracted; through the interface structure feature vector and the interface screenshot, each Activity group to be analyzed that is similar between the genuine application and the application to be tested is screened out, and then the similarity corresponding to each Activity group to be analyzed is calculated through the text feature vector, the control type feature vector and the control ID feature vector; finally, based on the similarity between the Activity running interfaces, the similarity SIMAPP between the genuine Android application and the Android application to be tested is calculated, and whether the Android application to be tested is a counterfeit application is determined according to the calculation result; compared with the current mainstream counterfeit APP detection algorithm, the main advantage of this method is that it has strong anti-obfuscation ability, high execution efficiency, and can effectively detect different types of application counterfeiting. In the application, not only traditional application counterfeiting behaviors can be detected, but also more complex and targeted application interface counterfeiting can be effectively detected.

[0090] The following describes the embodiments of the present invention in detail in conjunction with the accompanying drawings, but the present invention is not limited to the above embodiments, and various changes can be made within the knowledge scope of ordinary technicians in this field without departing from the purpose of the present invention.

Claims

1. A method for detecting Android counterfeit applications based on interface layout, based on genuine Android applications, detecting the corresponding Android applications to be tested, characterized in that: The steps include: Step A. Obtain screenshots of each Activity running interface in the Android application and layout information of each Activity running interface for the genuine Android application and the Android application to be tested, and then proceed to step B; Step B. For each Activity running interface in the genuine Android application and the Android application to be tested, according to the layout information of the Activity running interface, obtain the interface structure feature vector corresponding to the Activity running interface and the type feature vector corresponding to each type of preset feature of the Activity running interface, and then proceed to step C; Step C. constructing a pairwise combination of each Activity running interface in the genuine Android application and each Activity running interface in the tested Android application as each Activity group, and screening each Activity group according to the interface structure feature vector corresponding to each Activity running interface and the screenshot of each Activity running interface, and the obtained Activity groups are used as each Activity group to be analyzed, and then proceeding to step D; The above step C includes the following steps C1 to C3; Step C1. constructing a pairwise combination of each Activity running interface in the genuine Android application and each Activity running interface in the Android application to be tested as each Activity group, and proceeding to step C2; Step C2. For each Activity group, obtain the absolute value a of the difference in the number of layers in the layer set corresponding to the two Activity running interfaces in the Activity group, and obtain the absolute value b of the difference in the number of independent layers with the overlapping layer attribute of true in the independent layer set corresponding to the two Activity running interfaces in the Activity group, and then determine whether a is greater than a preset first threshold or b is greater than a preset second threshold. If so, delete the Activity group, otherwise define the Activity group as a primary Activity group; then enter step C3; Step C3. For each preliminary selected Activity group, apply the LMGist algorithm to obtain the spatial envelope feature vector of the screenshots of the two Activity running interfaces of the preliminary selected Activity group, and calculate the cosine similarity distance between the two spatial envelope feature vectors to determine whether the cosine similarity distance is greater than a preset third threshold. If so, define the preliminary selected Activity group as the Activity group to be analyzed, otherwise delete the preliminary selected Activity group; Step D. According to the type feature vectors of the preset types of features corresponding to the running interfaces of each Activity in the genuine Android application and the Android application to be tested, for each Activity group to be analyzed, the feature similarity of the preset types of features corresponding to the Activity group to be analyzed is obtained, and then the feature similarity of the preset types of features corresponding to the Activity group to be analyzed is obtained, and then the process proceeds to step E; In the above step D, according to the type feature vectors of the preset types of features corresponding to the running interfaces of each Activity in the genuine Android application and the Android application to be tested, the following operations are performed for each Activity group to be analyzed, to obtain the feature similarity of the preset types of features corresponding to the Activity group to be analyzed, and then obtain the feature similarity of the preset types of features corresponding to the Activity group to be analyzed, and then enter step E; Operation: For each preset type feature, the type feature vector f corresponding to the type feature of the two Activity running interfaces in the Activity group to be analyzed is A 、f B , according to the following formula: Get the feature similarity SIM(f A ,f B ), where I represents the type feature vector f of one of the Activity running interfaces in the Activity group to be analyzed corresponding to the type feature A The number of feature elements in , J represents the type feature vector f of another Activity running interface in the Activity group to be analyzed corresponding to the type feature B The number of characteristic elements in C A,i The type feature vector f that represents the type feature corresponding to one of the Activity running interfaces in the Activity group to be analyzed A The i-th characteristic element in C B,j The type feature vector f that represents the type feature of another Activity running interface in the Activity group to be analyzed B The jth characteristic element in , and SIM(C A,i ,C B,j ) is calculated as follows: Then, the feature similarity of each type of preset feature corresponding to the Activity group to be analyzed is obtained; Step E. For each Activity group to be analyzed, for each judgment condition that the feature similarity of each type of feature preset in the Activity group to be analyzed is not less than the feature similarity threshold of the corresponding type, if at least one judgment condition is met, the similarity corresponding to the Activity group to be analyzed is defined as 1; if all judgment conditions are not met, the similarity corresponding to the Activity group to be analyzed is defined as 0; then the similarities corresponding to each Activity group to be analyzed are obtained, and then step F is entered; Step F. Obtain the sum of similarities G corresponding to each Activity group to be analyzed, and then use the following formula: The similarity SIMAPP between the genuine Android application and the Android application to be tested is obtained, and it is determined whether the similarity SIMAPP is greater than a preset application similarity threshold. If so, the Android application to be tested is determined to be a counterfeit application, otherwise, the Android application to be tested is determined to be a non-counterfeit application; wherein U and V represent the number of Activity running interfaces in the genuine Android application and the number of Activity running interfaces in the Android application to be tested, respectively.

2. According to claim 1, a method for detecting Android counterfeit applications based on interface layout, characterized in that: In the step A, for the genuine Android application and the Android application to be tested, the following steps A1 to A3 are executed respectively to obtain screenshots of each Activity running interface in the Android application and layout information of each Activity running interface, and then proceed to step B; Step A1. Use ApkTool to decompress and decompile the APK of the Android application, obtain the compilation result corresponding to the Android application, and proceed to step A2; Step A2. Filter out the third-party library Activities registered in AndroidManifest.xml in the compilation result, and add intent-filter nodes, action subnodes, and category subnodes to the remaining Activities in the compilation result, and then package the compilation result to form an APK to be processed, and then proceed to step A3; Step A3. Install the APK to be processed based on the Android simulator, start each Activity in the APK to be processed by Appium, call the getScreenshotAs() function provided by Appium, obtain the screenshot of each Activity running interface on the Android simulator, and call the getPageSource() function provided by Appium to obtain the layout information of each Activity running interface on the Android simulator.

3. According to claim 1, a method for detecting Android counterfeit applications based on interface layout, characterized in that: In the step B, for each Activity running interface in the genuine Android application and the Android application to be tested, the following steps B1 to B4 are executed to obtain the interface structure feature vector corresponding to the Activity running interface and the preset feature vectors of each type, and then proceed to step C; Step B1. According to the layout information of the Activity running interface, traverse each control in the layout information in turn, extract the upper and lower bounds of the vertical coordinate from the bounds attribute of the control, construct each layer and each control contained in each layer, and then combine each layer to form a layer set corresponding to the Activity running interface, and then enter step B2; Step B2. For the layer set corresponding to the Activity running interface, each independent layer is obtained by merging adjacent layers containing the same control type and the same number of controls to form an independent layer, and the overlapping layer attribute of each independent layer is set to true. The remaining layers are directly used as independent layers, and the overlapping layer attribute of each independent layer is set to false. Then, the independent layers are combined to form the independent layer set corresponding to the Activity running interface, and then the process proceeds to step B3; Step B3. The number of layers in the layer set corresponding to the Activity running interface, the number of independent layers in the corresponding independent layer set, and the number of independent layers with overlapping layer attributes of true in the corresponding independent layer set are combined to form the interface structure feature vector corresponding to the Activity running interface, and then proceed to step B4; Step B4: traverse each independent layer in the independent layer set corresponding to the Activity running interface, and obtain the type feature vectors corresponding to each type of preset feature of the Activity running interface.

4. According to claim 3, a method for detecting Android counterfeit applications based on interface layout, characterized in that: The step B1 includes the following steps B1-1 to B1-4; Step B1-1. Initialize l=1, k=1, and proceed to step B1-2; Step B1-2. According to the layout information of the Activity running interface, traverse the lth control in the layout information, extract the upper and lower bounds of the ordinate from the bounds attribute of the control as the upper and lower bounds corresponding to the lth control, and enter step B1-3; Step B1-3. If l=1, the upper and lower bounds corresponding to the lth control are used as the upper and lower bounds of the kth layer, and the lth control is added to the kth layer, and then enter step B1-4; If l>1, determine whether the upper and lower bounds corresponding to the lth control are contained in the upper and lower bounds of the kth layer. If so, add the lth control to the kth layer and proceed to step B1-4; otherwise, use the upper and lower bounds corresponding to the lth control as the upper and lower bounds of the k+1th layer, add the lth control to the k+1th layer, then add 1 to the value of k and proceed to step B1-4; Step B1-4. Determine whether l is equal to the number L of controls in the layout information of the Activity running interface. If so, the layer set corresponding to the Activity running interface is composed of each layer and each control contained in each layer; otherwise, update the value of l by adding 1 and return to step B1-2.

5. According to claim 3, a method for detecting Android counterfeit applications based on interface layout, characterized in that: The preset feature vectors of various types include text feature vectors. In step B4, each independent layer in the independent layer set corresponding to the Activity running interface is traversed, and the text of the text or content-desc of each control contained in the independent layer is saved in the text feature set corresponding to the independent layer, so as to obtain the text feature sets corresponding to each independent layer respectively, and the text feature vector corresponding to the Activity running interface is composed of each text feature set.

6. According to claim 3, a method for detecting Android counterfeit applications based on interface layout, characterized in that: The preset feature vectors of each type include control type feature vectors. In step B4, each independent layer in the independent layer set corresponding to the Activity running interface is traversed, and the text of the class attribute of each control contained in the independent layer is saved in the control type feature set corresponding to the independent layer, so as to obtain the control type feature sets corresponding to each independent layer respectively, and the control type feature vector corresponding to the Activity running interface is composed of each control type feature set.

7. According to claim 3, a method for detecting Android counterfeit applications based on interface layout, characterized in that: The preset feature vectors of each type include control ID feature vectors. In step B4, each independent layer in the independent layer set corresponding to the Activity running interface is traversed, and the text of the resource-id attribute of each control contained in the independent layer is saved in the control ID feature set corresponding to the independent layer, so as to obtain the control ID feature sets corresponding to each independent layer respectively, and the control ID feature vector corresponding to the Activity running interface is composed of each control ID feature set.

Images