Power mobile application vulnerability detection method, device and electronic equipment

Abstract

The present invention provides a method, device, and electronic device for detecting vulnerabilities in electric mobile applications. The method comprises: obtaining an electric mobile application APK package, determining the target intent field in the exposed component and the type of data received by the exposed component; generating a current round of test cases based on the target intent field for testing, and stopping testing if a vulnerability is detected; if no vulnerability is detected, determining whether each test case in the current round of test cases has been received, and if not, discarding the test case; if received, calculating the fitness of the test case based on the execution time; screening the multiple test cases based on their fitness, performing cross-mutation, and generating the next round of test cases; using the next round of test cases as the current round of test cases, and repeating the above steps until the number of iterations reaches an upper limit. The present invention solves the problem of difficulty in detecting potential security threats in electric mobile applications, which exists in related technologies.

Description

Technical Field

[0001] The present invention relates to the field of power mobile terminal security technology, and in particular to a power mobile application vulnerability detection method, device and electronic equipment. Background Art

[0002] With the advancement of smart grid construction and the rapid development of power mobile Internet services, more and more mobile terminals are connected to the information intranet of power enterprises and interact with the application systems of the intranet, which greatly improves the efficiency of power system work and production operations; however, the access of a large number of power mobile terminals also reduces the attack cost of attackers. Attackers exploit security vulnerabilities of mobile terminals to execute malicious code, obtain device permissions, steal user information, and launch attacks on the information intranet of power enterprises, increasing the security risk of the power grid. At present, it is difficult to detect potential security threats of power mobile terminals in power mobile application vulnerability detection. How to effectively detect security vulnerabilities of power mobile terminals and discover potential security risks before the power mobile terminals are connected to the power system is of great significance to ensuring the stable operation of the power system. Therefore, there is a problem in the existing technology that it is difficult to detect potential security threats in power mobile applications. Summary of the Invention

[0003] The present invention provides a method, device and electronic device for detecting vulnerabilities in power mobile applications, so as to at least solve the problem in the related art that it is difficult to detect potential security threats in power mobile applications.

[0004] According to a first aspect of an embodiment of the present invention, a method for detecting vulnerabilities in electric mobile applications is provided, the method comprising: obtaining the electric mobile application apk package, determining the target intent field in the exposed component and the data type received by the exposed component based on the apk package; generating a current round of test cases based on the target intent field using a null value and a boundary value of the data type, wherein the current round of test cases includes multiple test cases; sending the current round of test cases for testing to determine whether a vulnerability is detected, and if a vulnerability is detected, stopping the test and recording the vulnerability information; if no vulnerability is detected, recording the vulnerability information based on whether the log changes. Determine whether each test case in the current round of test cases is received. If the test case is not received, discard the test case; if the test case is received, calculate the fitness of the test case according to the execution time; screen and cross-mutate the multiple test cases according to the fitness of multiple test cases to generate the next round of test cases; use the next round of test cases as the current round of test cases, execute and send the current round of test cases, and determine whether vulnerabilities are detected. If no vulnerabilities are detected, determine whether it is received. If it is received, calculate the fitness of each test case in the current round of test cases and generate the next round of test cases until the number of iterations reaches the upper limit.

[0005] Optionally, the screening and cross-mutation of the multiple test cases according to their fitness to generate the next round of test cases includes: directly using the test case with the largest fitness value among the multiple test cases as one of the test cases for the next round; screening the other test cases other than the test case with the largest fitness value among the multiple test cases using a roulette wheel selection method to obtain target test cases; performing a cross operation on the target test cases according to field values, and performing a mutation operation on the target test cases according to data types to generate the next round of test cases.

[0006] Optionally, the cross operation on the target test case according to the field value and the mutation operation on the target test case according to the data type include: exchanging the Data and Extra fields in any two of the target test cases; randomly mutating the host, port and path fields in the Data field in the intent according to the scheme field type; and mutating the Extra field in the intent according to the data type.

[0007] Optionally, the mutating of the Extra field in the intent according to the data type includes: mutating the data type allowed to be received by the program to other types, mutating the numerical value of the numerical type data, mutating the characters of the character type data to different types of character values, randomly mutating the string type data according to the field type, and mutating the array type data according to the array element value and array length.

[0008] Optionally, calculating the fitness of the test case according to the execution time includes: determining a fitness function according to a timestamp in a log of changes corresponding to the test case, and the fitness function formula is as follows: Where, T n T0 is the time when the test case starts to execute and the last time the log changes after the test case is executed.

[0009] Optionally, obtaining the electric mobile application apk package and determining the target intent field in the exposed component and the data type received by the exposed component based on the apk package includes: decompiling the electric mobile application apk package to obtain program source code and a configuration file; determining the exposed component and the path of the exposed component based on the configuration file, and obtaining the program source code corresponding to the exposed component based on the program source code, the exposed component and the path of the exposed component; and determining the target intent field in the exposed component and the data type received by the exposed component based on the program source code corresponding to the exposed component.

[0010] According to the second aspect of the embodiment of the present invention, a power mobile application vulnerability detection device is also provided, which includes: a determination module for obtaining the power mobile application apk package, and determining the target intent field in the exposed component and the data type received by the exposed component according to the apk package; a generation module for generating this round of test cases for the target intent field based on a null value and a boundary value of the data type, wherein the test cases in this round include multiple test cases; a first judgment module for sending the test cases in this round for testing to determine whether a vulnerability is detected, and if a vulnerability is detected, stopping the test and recording the vulnerability information; a second judgment module for determining whether a vulnerability is detected according to whether a log is generated if no vulnerability is detected. A fitness calculation module is used to determine whether each test case in the current round of test cases is received, and if the test case is not received, the test case is discarded; a fitness calculation module is used to calculate the fitness of the test case according to the execution time if the test case is received; a cross-mutation module is used to screen and cross-mutate the multiple test cases according to their fitness, and generate the next round of test cases; an iteration module is used to use the next round of test cases as the current round of test cases, execute and send the current round of test cases, and determine whether a vulnerability is detected. If no vulnerability is detected, determine whether it is received; if it is received, calculate the fitness of each test case in the current round of test cases and generate the next round of test cases until the number of iterations reaches an upper limit.

[0011] Optionally, the crossover and mutation module includes: a retention unit, used to directly use the test case with the largest fitness value among the multiple test cases as one of the test cases for the next round; an acquisition unit, used to screen the test cases other than the test case with the largest fitness value among the multiple test cases using a roulette wheel selection method to obtain a target test case; and a generation unit, used to perform a crossover operation on the target test case according to the field value, and perform a mutation operation on the target test case according to the data type to generate the test cases for the next round.

[0012] Optionally, the generation unit includes: an exchange submodule, used to exchange the Data and Extra fields in any two of the target test cases; a random mutation submodule, used to randomly mutate the host, port and path fields in the Data field in the intent according to the scheme field type; and a mutation submodule, used to mutate the Extra field in the intent according to the data type.

[0013] Optionally, the mutation submodule includes: a mutation subunit, which is used to mutate the data type allowed to be received by the program into other types, mutate the numerical value of the numerical type data, mutate the characters of the character type data into different types of character values, randomly mutate the string type data according to the field type, and mutate the array type data according to the array element value and array length.

[0014] Optionally, the fitness calculation module includes: a fitness calculation unit, configured to determine a fitness function according to a timestamp in a log of changes corresponding to the test case, wherein the fitness function formula is as follows: Where, T n T0 is the time when the test case starts to execute and the last time the log changes after the test case is executed.

[0015] Optionally, the determination module includes: a decompilation unit, used to decompile the electric mobile application apk package to obtain program source code and a configuration file; an acquisition unit, used to determine the exposed component and the path of the exposed component according to the configuration file, and obtain the program source code corresponding to the exposed component according to the program source code, the exposed component and the path of the exposed component; a determination unit, used to determine the target intent field in the exposed component and the data type received by the exposed component according to the program source code corresponding to the exposed component.

[0016] According to the third aspect of an embodiment of the present invention, an electronic device is also provided, including a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other through the communication bus; wherein the memory is used to store computer programs; and the processor is used to execute the method steps in any of the above embodiments by running the computer program stored on the memory.

[0017] According to a fourth aspect of an embodiment of the present invention, a computer-readable storage medium is further provided, in which a computer program is stored. The computer program is configured to execute the method steps in any of the above embodiments when run.

[0018] In an embodiment of the present invention, the target intent field in the exposed component and the data type received by the exposed component are determined by obtaining the APK package of the electric mobile application; a current round of test cases is generated based on the target intent field; the current round of test cases is sent for testing to determine whether a vulnerability is detected; if a vulnerability is detected, the test case is stopped; if no vulnerability is detected, the fitness of each test case in the current round of test cases is determined to be received; if not, the test case is discarded; if received, the fitness of the test case is calculated based on the execution time; based on the fitness of the multiple test cases, the multiple test cases are screened and cross-mutated to generate the next round of test cases; the next round of test cases are used as the current round of test cases, and the above steps are repeated until the number of iterations reaches an upper limit. Since intent objects are constructed as test cases based on the intent mechanism for communication between application components, and the test cases are cross-mutated based on the concept of genetic algorithm, various unexpected inputs are provided and abnormal results are monitored to discover software vulnerabilities. This achieves the purpose of detecting potential security threats in electric mobile applications, thereby solving the problem of difficulty in detecting potential security threats in electric mobile applications in related technologies.

[0019] In an embodiment of the present invention, test cases are generated based on the target intent field using null values ​​and boundary values ​​of the data type. Since null values ​​or boundary values ​​of the Data field and the Extras field in the intent field can easily cause application crash exceptions, initial test cases are generated based on null values ​​and boundary values, thereby achieving the effect of improving detection efficiency.

[0020] In an embodiment of the present invention, the reference side channel idea is proposed to calculate the fitness of the test case based on the execution time. Since the execution time reflects the amount of executed code to a certain extent, it further reflects the size of the coverage, an important criterion for selecting fuzzy test cases, thereby achieving the purpose of improving test efficiency.

[0021] In the embodiment of the present invention, the test cases with the highest fitness are retained as the next round of test cases without cross-mutation, and the remaining test cases are screened using the roulette wheel selection method, thereby reducing the scale of screened cases and improving screening efficiency.

[0022] In an embodiment of the present invention, fuzzy testing of power mobile applications is performed based on the concept of genetic algorithm, which can construct more effective test cases, detect security vulnerabilities of power mobile applications, timely discover potential security risks, and improve the overall security protection capabilities of power mobile terminals. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0024] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0025] Figure 1 is a schematic diagram of a hardware environment of an optional power mobile application vulnerability detection method according to an embodiment of the present invention;

[0026] Figure 2 is a flow chart of an optional method for detecting vulnerabilities in power mobile applications according to an embodiment of the present invention;

[0027] Figure 3 1 is a schematic diagram of the overall process of an optional power mobile application vulnerability detection method according to an embodiment of the present invention;

[0028] Figure 4 is a structural block diagram of an optional power mobile application vulnerability detection device according to an embodiment of the present invention;

[0029] Figure 5 is a structural block diagram of an optional electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0030] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0031] It should be noted that, in the description of the present invention, the terms "first," "second," and the like are used to distinguish similar objects and are not necessarily used to describe a specific order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate, such that the embodiments of the present invention described herein can be implemented in an order other than that illustrated or described herein. Furthermore, the terms "including," "having," and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include additional steps or elements not expressly listed or inherent to such process, method, product, or apparatus. The terms "mounted," "connected," and "connected" are to be broadly construed, and may refer to fixed, removable, or integral connections; mechanical or electrical connections; direct or indirect connections through an intermediary; internal communication between two components; wireless or wired connections. Those skilled in the art will understand the specific meanings of these terms in the present invention.

[0032] According to one aspect of an embodiment of the present invention, a method for detecting vulnerabilities in power mobile applications is provided. Optionally, in this embodiment, the method for detecting vulnerabilities in power mobile applications can be applied to Figure 1 In the hardware environment shown in the figure. Figure 1 As shown, the terminal 102 may include a memory 104, a processor 106, and a display 108 (optional component). The terminal 102 may be communicatively connected to a server 112 via a network 110. The server 112 may be configured to provide services (such as application services) for the terminal or a client installed on the terminal. A database 114 may be provided on or independent of the server 112 to provide data storage services for the server 112. In addition, a processing engine 116 may be running on the server 112, which may be configured to execute the steps performed by the server 112.

[0033] Optionally, the terminal 102 may be, but is not limited to, a terminal capable of computing data, such as a mobile terminal (e.g., a mobile phone, tablet computer), a laptop computer, or a PC (Personal Computer). The aforementioned network may include, but is not limited to, a wireless network or a wired network. Wireless networks include Bluetooth, Wi-Fi (Wireless Fidelity), and other networks that enable wireless communication. Wired networks may include, but are not limited to, wide area networks, metropolitan area networks, and local area networks. The aforementioned server 112 may include, but is not limited to, any hardware device capable of computing.

[0034] Furthermore, in this embodiment, the above-described power mobile application vulnerability detection method can also be applied, but is not limited to, to a standalone processing device with relatively powerful processing capabilities, without requiring data exchange. For example, the processing device can be, but is not limited to, a terminal device with relatively powerful processing capabilities. That is, the various operations in the above-described power mobile application vulnerability detection method can be integrated into a single standalone processing device. This is merely an example and is not intended to be limiting in this embodiment.

[0035] Optionally, in this embodiment, the above-mentioned power mobile application vulnerability detection method can be executed by the server 112, or by the terminal 102, or by both the server 112 and the terminal 102. The power mobile application vulnerability detection method of the embodiment of the present invention can also be executed by the client installed on the terminal 102.

[0036] Taking the power mobile application vulnerability detection method applied to the central processing unit as an example, Figure 2 FIG is a flow chart of an optional method for detecting vulnerabilities in power mobile applications according to an embodiment of the present invention. Figure 2 As shown, the process of the method may include the following steps:

[0037] Step S201, obtain the apk package of the power mobile application, and determine the target intent field in the exposed component and the data type received by the exposed component based on the apk package. Optionally, the apk package (Android application package) is an application package file format used by the Android operating system for distributing and installing mobile applications and middleware. First, obtain the apk package of the power mobile application, determine the exposed components and the data type received by the exposed components, and specifically, confirm whether external applications are allowed to call the component based on the component tag (android: exported). When a component allows external applications to call it, it is called an exposed component, and the exposed component may have security issues. Therefore, the present invention uses the intent mechanism for communication between application components to detect vulnerabilities. The intent object consists of six parts: Component name, Action, Data, Extra, Category, and Flag. Among them, the Component name field indicates the component name; the Action field determines the action to be performed by the component; the Data and Extra fields are used to transmit data. By locating the getXXXExtras() function, the Key value received by the Extra field in the exposed component and the type of Value, that is, the data type received by the exposed component, can be obtained; the Category field contains the type information of the component that processes the intent; the Flag field represents a flag, which can manage the task stack that stores the application display interface. This method focuses on the Component name, Action, Data, and Extra fields, that is, the Component name, Action, Data, and Extra fields are used as the target intent fields. Other fields can also be selected for testing according to specific needs.

[0038] Step S202: Generate this round of test cases based on the target intent field using null values ​​and data type boundary values. This round of test cases includes multiple test cases. Optionally, based on the results of the previous analysis, create a test case dataset for each exposed component. The format of each test case data in this dataset is:

[0039] {Component name: component name XXX

[0040] Action: XXX

[0041] Data:XXX

[0042] Extra:{Key:”XXX”;Value:XXX}

[0043] }

[0044] Among them, Component name represents the component name, which can be obtained in the AndroidManifest.xml file according to the tag android:name="XXX". The Action field indicates the action to be performed by the receiving component, which is usually of string type. The Action field value that the component expects to receive can be obtained through the getAction() function in the AndroidManifest.xml file or the source code. The Data field is the Uri of the data to be operated, in the format of scheme: / / host:port / path. The Extra field is a key-value pair type of data, consisting of two parts (Key, Value). By locating the getXXXExtras() function in the source code, the Key value and Value type of the Extra received by the program can be obtained. For example, in the source code: str = paramIntent.getStringExtra("appCode"); Therefore, the Extra field received by the program is a data with a Key name of "appCode" and a Value of String type.

[0045] As found in the early tests, the probability of exceptions being caused is high when the Action, Data, and Extra fields are null or at the boundary value. This is because the program does not perform operations such as null value processing on the corresponding fields when obtaining the intent object. Therefore, the initial test case, i.e., the test case for this round, is constructed according to the following form:

[0046] {Component name: component name XXX

[0047] Action: null

[0048] Data: null

[0049] Extra: {Key: "XXX"; Value: null or the boundary value of this type}

[0050] }

[0051] It should be noted that each exposed component includes a test case data set, and each test case data set includes multiple test cases, that is, this round of test cases contains multiple test cases.

[0052] Step S203, send the test cases of this round for testing to determine whether a vulnerability is detected. If a vulnerability is detected, stop testing and record the vulnerability information. Optionally, send the test cases of this round generated in step S202 to the electric mobile application, and determine whether a vulnerability is detected by analyzing the underlying system logs and observing the application running status. This embodiment does not specifically limit the method of sending test cases. For example, the Drozer tool can be used to send test cases to applications on mobile terminals. If a vulnerability is detected, stop testing and record the vulnerability information. Some initial test cases can detect unauthorized vulnerabilities in components, that is, bypassing the normal use logic of the software to start related components, such as starting a logged-in component without logging in. This is obviously not in line with the norm. This embodiment determines it as an unauthorized vulnerability. If the initial test case detects an unauthorized vulnerability, stop testing the component and record it.

[0053] Step S204, if no vulnerability is detected, then the test cases in this round of test cases are judged to be received based on whether the log changes. If the test cases are not received, the test cases are discarded. Alternatively, if no vulnerability is detected after sending the test cases in this round, then the test cases in this round of test cases are judged to be received based on whether the log changes. Specifically, whether the test cases are received is judged by observing the events buffer log of the bottom layer of the Android system. Among them, each log in the events buffer provides detailed time, process ID, thread ID, log label and log detailed information. The adb tool can be used to view the log information and observe the changes in the log, or other tools or methods can be used. If the system log does not change after a test case is sent, it means that the test case has not been received, so the test case is discarded.

[0054] Step S205: If the test case is received, the fitness of the test case is calculated based on the execution time. Optionally, if the system log changes after a test case is sent, it means that the test case has been received but has not caused any application anomalies. In this case, the test case is retained and its fitness is calculated.

[0055] Step S206: Screen and cross-mutate the test cases based on their fitness to generate the next round of test cases. Optionally, screen the test cases based on the fitness of the remaining test cases, cross-mutate the screened test cases, and generate the next round of test cases.

[0056] In step S207, the next round of test cases are used as the current round of test cases, and the current round of test cases are sent to determine whether a vulnerability is detected. If no vulnerability is detected, it is determined whether it has been received. If it has been received, the fitness of each test case in the current round of test cases is calculated, and the next round of test cases is generated until the number of iterations reaches the upper limit. Optionally, the next round of test cases generated in step S206 are used as the current round of test cases, and steps S203, S204, S205, and S206 are repeated until the number of iterations reaches the upper limit. If the number of iterations reaches the upper limit, the component is tested, and otherwise, the component is tested continuously based on the generated new test cases.

[0057] In an embodiment of the present invention, the target intent field in the exposed component and the data type received by the exposed component are determined by obtaining the APK package of the electric mobile application; a current round of test cases is generated based on the target intent field; the current round of test cases is sent for testing to determine whether a vulnerability is detected; if a vulnerability is detected, the test case is stopped; if no vulnerability is detected, the fitness of each test case in the current round of test cases is determined to be received; if not, the test case is discarded; if received, the fitness of the test case is calculated based on the execution time; based on the fitness of the multiple test cases, the multiple test cases are screened and cross-mutated to generate the next round of test cases; the next round of test cases are used as the current round of test cases, and the above steps are repeated until the number of iterations reaches an upper limit. Since intent objects are constructed as test cases based on the intent mechanism for communication between application components, and the test cases are cross-mutated based on the concept of genetic algorithm, various unexpected inputs are provided and abnormal results are monitored to discover software vulnerabilities. This achieves the purpose of detecting potential security threats in electric mobile applications, thereby solving the problem of difficulty in detecting potential security threats in electric mobile applications in related technologies.

[0058] As an optional embodiment, based on the fitness of multiple test cases, multiple test cases are screened and cross-mutated to generate the next round of test cases, including: directly using the test case with the largest fitness value among the multiple test cases as one of the test cases for the next round; using a roulette wheel selection method to screen the test cases other than the test case with the largest fitness value among the multiple test cases to obtain target test cases; performing a cross operation on the target test cases according to the field value, and performing a mutation operation on the target test cases according to the data type to generate the next round of test cases.

[0059] Optionally, when generating the next round of test cases, the test case with the highest fitness value among the multiple test cases is directly selected as one of the test cases for the next round. The remaining test cases are screened using a roulette wheel selection method, and the multiple test cases obtained after screening, i.e., the target test cases, are subjected to crossover and mutation. Specifically, the crossover and mutation method includes: performing a crossover operation on the target test cases based on the field value, and performing a mutation operation on the target test cases based on the data type.

[0060] In the embodiment of the present invention, the test cases with the highest fitness are retained as the next round of test cases without cross-mutation, and the remaining test cases are screened using the roulette wheel selection method, thereby reducing the scale of screened cases and improving screening efficiency.

[0061] As an optional embodiment, cross-checking the target test cases based on field values ​​and mutating the target test cases based on data types include: swapping the Data and Extra fields in any two target test cases; randomly mutating the host, port, and path fields in the Data field of the intent based on the scheme field type; and mutating the Extra field in the intent based on the data type. Alternatively, suppose that test cases 1 and 2 in the target test cases are as follows:

[0062] Test case 1:

[0063] {Component name: com.freshpower.android.elec.widget.CaptureActivityAction: ACTION_PICK

[0064] Data: tel: / / 123

[0065] Extra:{Key:”userid”Value:123456;

[0066] Key:”url”Value:”content: / / com.android.contacts / contacts / 1”}

[0067] }

[0068] Test case 2:

[0069] {Component name: com.freshpower.android.elec.widget.CaptureActivity

[0070] Action: ACTION_VIEW

[0071] Data: content: / / com.android.contacts / contacts / 1

[0072] Extra:{Key:”userid”Value:987;

[0073] Key:”url”Value:”xxxxxx”}

[0074] }

[0075] Perform a cross operation on these two test cases, that is, swap the Data and Extra fields. The test cases after the cross operation are as follows:

[0076] Test case 1:

[0077] {Component name: com.freshpower.android.elec.widget.CaptureActivity

[0078] Action: ACTION_PICK

[0079] Data: content: / / com.android.contacts / contacts / 1

[0080] Extra:{Key:”userid”Value:987;

[0081] Key:”url”Value:”xxxxxx”}

[0082] }

[0083] Test case 2:

[0084] {Component name: com.freshpower.android.elec.widget.CaptureActivity

[0085] Action: ACTION_VIEW

[0086] Data: tel: / / 123

[0087] Extra:{Key:”userid”Value:123456;

[0088] Key:”url”Value:”content: / / com.android.contacts / contacts / 1”}

[0089] }

[0090] Considering that the various fields in the initial use case are empty, there is no need to generate test cases with empty fields during the mutation process. For the Data field in the intent, since the Data field is usually of Uri type and satisfies the scheme: / / host:port / path format, the schemes usually include tel: / / (number data format, followed by the phone number), mailto: / / (mail data format, followed by the email recipient address), smsto: / / (short message data format, followed by the SMS receiving number), content: / / (content data format, followed by the content to be read), file: / / (file data format, followed by the file path), http: / / (web page format, followed by the specific web page address), and other types. During the mutation process, the scheme field does not need to be mutated, and only needs to be selected from the above types; the mutation rule of the host field is determined by the scheme type. When the scheme field is tel: / / and smsto: / / , the host field is a randomly mutated string of numbers; when the scheme field is mailto: / / , the host field is a randomly mutated email address; when the scheme field is content: / / and file: / / , the host field is a randomly mutated file address; when the scheme field is http: / / , the host field is a randomly mutated domain name; the port field represents the port number and can be randomly mutated to a string of numbers or an empty value; the path field is the detailed address of the file or the content following the domain name in the URL, and can be randomly mutated to a string separated by ' / ' or an empty value. In the embodiment of the present invention, a specific cross-mutation operation method for the test case is given in combination with possible vulnerabilities.

[0091] As an optional embodiment, mutating the Extra field in the intent according to the data type includes: mutating the data type allowed to be received by the program to other types, mutating the value of the numeric type data, mutating the characters of the character type data to different types of character values, randomly mutating the string type data according to the field type, and mutating the array type data according to the array element value and array length. Optionally, for the Extra field in the intent, since the Extra field received by the application includes multiple types, its mutation strategy mainly includes the following two: (1) mutating the Extra field to other types other than the data type allowed to be received by the program to discover type conversion vulnerabilities in the program. For example, if the data type of the Extra field allowed to be received by the program is int, it can be mutated to float, double, char or String type, etc.; if the data type of the Extra field allowed to be received by the program is int[] type, it can be mutated to float[], float[], char[] or String[] type, etc. (2) For numeric types such as int, float, double, etc., mutate according to the numeric value. For example, the x value of int type can be mutated to x=-x, x=x^2, x=-x^2, etc.; for character data of char type, it can be mutated to a char value of a different type than the current one, such as mutating the char type '1' to the letter 'a', the symbol '&', or the operator '+', etc.; for string data of String type, considering that many programs use the value of String type to pass address data such as Uri, random mutation can be performed with reference to the Data mutation strategy; for array type data such as float[], float[], char[], String[], and boolean[], in addition to mutating the value of the array element, the length of the array can also be mutated, where the mutation of the array element can refer to the above mutation strategy. In the embodiment of the present invention, a specific mutation operation method for the Extra field in the test case is given in combination with possible vulnerabilities.

[0092] As an optional embodiment, calculating the fitness of the test case based on the execution time includes: determining a fitness function based on the timestamp in the change log corresponding to the test case. The fitness function formula is as follows:

[0093]

[0094] Where, T n is the last time the log changes after the test case is executed, T o The time when the test case starts to execute. nIt can be obtained from the system log, and the time accurate to milliseconds can be obtained based on the timestamp part of the log information. o You can directly get the system time through the function. To avoid loss of accuracy, the obtained T n and T o The calculation is performed in milliseconds. The fitness of each retained test case is calculated according to the fitness function formula for screening.

[0095] In an embodiment of the present invention, the reference side channel idea is proposed to calculate the fitness of the test case based on the execution time. Since the execution time reflects the amount of executed code to a certain extent, it further reflects the size of the coverage, an important criterion for selecting fuzzy test cases, thereby achieving the purpose of improving test efficiency.

[0096] As an optional embodiment, obtaining the electric mobile application apk package and determining the target intent field in the exposed component and the data type received by the exposed component based on the apk package include: decompiling the electric mobile application apk package to obtain the program source code and configuration file; determining the exposed component and the path of the exposed component based on the configuration file, and obtaining the program source code corresponding to the exposed component based on the program source code, the exposed component and the path of the exposed component; and determining the target intent field in the exposed component and the data type received by the exposed component based on the program source code corresponding to the exposed component.

[0097] Optionally, obtain the apk package of the power mobile application, use apkTool to decompress the apk package to obtain the resource files and AndroidManifest.xml file (configuration file), then use dex2jar to convert the apk package into a jar package, and use jd-gui to open the converted jar package to obtain the source code of the application. Analyze the exposed components in the application based on the AndroidManifest.xml file. Specifically, if the exported attribute in the component tag of the AndroidManifest.xml file is true or the component tag contains <intent-filter>This indicates that the component is an exposed component. The name of the component registered in AndroidManifest.xml is the path of the component in the entire application package. After determining the exposed component, you can use this path to find the corresponding program source code in the decompiled APK package. Then, based on the corresponding program source code, you can determine the target intent field in the exposed component and the data type received by the exposed component.

[0098] As an optional embodiment, Figure 3 This is an overall flow chart of an optional power mobile application vulnerability detection method, such as Figure 3 As shown, the APK package is first decompiled and the exposed components are retrieved. This step is to obtain the target intent field and the data type accepted by the exposed components, which are required for constructing test cases. An initial test case is then constructed, generated based on the target intent field using a null value and the boundary value of the data type. The test case is then sent to the designated app, essentially sending the initial test case to the power mobile app to be tested. A determination is made as to whether a vulnerability is detected. If so, the test case is terminated. If not, the log is checked for changes. If not, the test case is discarded. If so, the test case's fitness is calculated. The current round of test cases is then determined to be complete. If not, the test case is sent to the designated app and the subsequent steps are executed. If so, a test case is selected based on the fitness, and crossover and mutation are performed on the test case to generate the next round of test cases. The test case is then determined to have reached the upper limit for the number of iterations. If so, the test case is terminated. If not, the test case is sent to the designated app and the subsequent steps are executed.

[0099] According to another aspect of an embodiment of the present invention, a power mobile application vulnerability detection device for implementing the above-mentioned power mobile application vulnerability detection method is also provided. Figure 4 is a structural block diagram of an optional power mobile application vulnerability detection device according to an embodiment of the present invention, such as Figure 4 As shown, the device may include: a determination module 401, for obtaining the power mobile application apk package, and determining the target intent field in the exposed component and the data type received by the exposed component according to the apk package; a generation module 402, for generating this round of test cases based on the null value and the boundary value of the data type for the target intent field, wherein this round of test cases includes multiple test cases; a first judgment module 403, for sending this round of test cases for testing, and judging whether a vulnerability is detected. If a vulnerability is detected, the test is stopped and the vulnerability information is recorded; a second judgment module 404, for judging each test case in this round of test cases according to whether the log changes if no vulnerability is detected. Whether the test case is received, if not, the test case is discarded; the fitness calculation module 405 is used to calculate the fitness of the test case according to the execution time if the test case is received; the cross-mutation module 406 is used to screen and cross-mutate multiple test cases according to the fitness of multiple test cases to generate the next round of test cases; the iteration module 407 is used to use the next round of test cases as the current round of test cases, execute and send the current round of test cases, and determine whether vulnerabilities are detected. If no vulnerabilities are detected, determine whether it is received. If it is received, calculate the fitness of each test case in the current round of test cases and generate the next round of test cases until the number of iterations reaches the upper limit.

[0100] It should be noted that the determination module 401 in this embodiment can be used to execute the above step S201, the generation module 402 in this embodiment can be used to execute the above step S202, the first judgment module 403 in this embodiment can be used to execute the above step S203, the second judgment module 404 in this embodiment can be used to execute the above step S204, the fitness calculation module 405 in this embodiment can be used to execute the above step S205, the crossover and mutation module 406 in this embodiment can be used to execute the above step S206, and the iteration module 407 in this embodiment can be used to execute the above step S207.

[0101] This module constructs intent objects as test cases based on the intent mechanism used for communication between application components. Using genetic algorithms, these test cases are cross-mutated, providing various unexpected inputs and monitoring abnormal results to discover software vulnerabilities. This achieves the goal of detecting potential security threats in electric mobile applications, thereby resolving the difficulty of detecting potential security threats in related technologies.

[0102] As an optional embodiment, the crossover and mutation module includes: a retention unit, which is used to directly use the test case with the largest fitness value among multiple test cases as one of the test cases for the next round; an acquisition unit, which is used to use a roulette wheel selection method to screen other test cases other than the test case with the largest fitness value among the multiple test cases to obtain a target test case; and a generation unit, which is used to perform a crossover operation on the target test case according to the field value, and perform a mutation operation on the target test case according to the data type to generate the test case for the next round.

[0103] As an optional embodiment, the generation unit includes: an exchange submodule, used to exchange the Data and Extra fields in any two target test cases; a random mutation submodule, used to randomly mutate the host, port and path fields in the Data field in the intent according to the scheme field type; and a mutation submodule, used to mutate the Extra field in the intent according to the data type.

[0104] As an optional embodiment, the mutation submodule includes: a mutation subunit, which is used to mutate the data types allowed to be received by the program into other types, mutate the numerical values ​​of numerical type data, mutate the characters of character type data into different types of character values, randomly mutate string type data according to field type, and mutate array type data according to array element value and array length.

[0105] As an optional embodiment, the fitness calculation module includes: a fitness calculation unit, configured to determine a fitness function according to a timestamp in a log of changes corresponding to a test case. The fitness function formula is as follows: Where, T n The time when the log changes last after the test case is executed, and T0 is the time when the test case starts to execute.

[0106] As an optional embodiment, the determination module includes: a decompilation unit, used to decompile the power mobile application APK package to obtain the program source code and configuration file; an acquisition unit, used to determine the exposed component and the path of the exposed component based on the configuration file, and obtain the program source code corresponding to the exposed component based on the program source code, the exposed component and the path of the exposed component; a determination unit, used to determine the target intent field in the exposed component and the data type received by the exposed component based on the program source code corresponding to the exposed component.

[0107] It should be noted that the examples and application scenarios implemented by the above modules and corresponding steps are the same, but are not limited to the contents disclosed in the above embodiments. Figure 1 The hardware environment shown can be implemented through software or hardware, wherein the hardware environment includes a network environment.

[0108] According to another aspect of an embodiment of the present invention, an electronic device for implementing the above-mentioned power mobile application vulnerability detection method is also provided. The electronic device may be a server, a terminal, or a combination thereof.

[0109] Figure 5 is a structural block diagram of an optional electronic device according to an embodiment of the present invention, such as Figure 5 As shown, the system includes a processor 501, a communication interface 502, a memory 503, and a communication bus 504. The processor 501, the communication interface 502, and the memory 503 communicate with each other via the communication bus 504. The memory 503 is used to store computer programs. When the processor 501 executes the computer program stored in the memory 503, it implements the following steps:

[0110] Obtain the electric mobile application apk package, and determine the target intent field in the exposed component and the data type received by the exposed component based on the apk package; generate this round of test cases based on the target intent field using null values ​​and boundary values ​​of the data type, wherein this round of test cases contains multiple test cases; send this round of test cases for testing to determine whether a vulnerability is detected, and if a vulnerability is detected, stop testing and record the vulnerability information; if no vulnerability is detected, determine whether each test case in this round of test cases is received based on whether the log changes, and if the test case is not received, discard the test case; if the test case is received, calculate the fitness of the test case based on the execution time; based on the fitness of multiple test cases, screen and cross-mutate multiple test cases to generate the next round of test cases; use the next round of test cases as the test cases of this round, execute the steps of sending this round of test cases to determine whether a vulnerability is detected, and if no vulnerability is detected, determine whether it is received, and if it is received, calculate the fitness of each test case in this round of test cases and generate the next round of test cases until the number of iterations reaches the upper limit.

[0111] Optionally, in this embodiment, the communication bus may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus. The communication bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 5 The use of only one bold line in the figure does not imply that there is only one bus or only one type of bus. The communication interface is used for communication between the electronic device and other devices. The memory may include RAM or non-volatile memory, such as at least one disk storage device. Alternatively, the memory may be at least one storage device located remotely from the processor.

[0112] As an example, Figure 5 As shown, the memory 503 may include, but is not limited to, the determination module 401, generation module 402, first judgment module 403, second judgment module 404, fitness calculation module 405, crossover and mutation module 406, and iteration module 407 of the power mobile application vulnerability detection device. Furthermore, the memory 503 may also include, but is not limited to, other modules and units of the power mobile application vulnerability detection device, which will not be described in detail in this example.

[0113] The above-mentioned processor can be a general-purpose processor, which can include but is not limited to: CPU (Central Processing Unit), NP (Network Processor), etc.; it can also be DSP (Digital Signal Processing), ASIC (Application Specific Integrated Circuit), FPGA (Field-Programmable Gate Array) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. In addition, the above-mentioned electronic device also includes: a display for displaying the power mobile application vulnerability detection results. Optionally, the specific examples in this embodiment can refer to the examples described in the above embodiments, and this embodiment will not be repeated here.

[0114] It can be understood by those skilled in the art that Figure 5 The structure shown is for illustration only. The device for implementing the above-mentioned power mobile application vulnerability detection method may be a terminal device, which may be a smart phone (such as an Android phone, an iOS phone, etc.), a tablet computer, a PDA, a mobile Internet device (Mobile Internet Devices, MID), a PAD, and other terminal devices. Figure 5 The structure of the electronic device is not limited. For example, the terminal device may also include Figure 5 More or fewer components (such as network interfaces, display devices, etc.) shown in, or with Figure 5 Different configurations shown.

[0115] A person skilled in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing the hardware related to the terminal device through a program, and the program can be stored in a computer-readable storage medium, which can include: a flash drive, ROM, RAM, a magnetic disk or an optical disk, etc.

[0116] According to another aspect of an embodiment of the present invention, a storage medium is further provided. Optionally, in this embodiment, the storage medium can be used to execute the program code of the power mobile application vulnerability detection method.

[0117] Optionally, in this embodiment, the above-mentioned storage medium may be located on at least one network device among the multiple network devices in the network shown in the above-mentioned embodiment.

[0118] Optionally, in this embodiment, the storage medium is configured to store program codes for executing the following steps:

[0119] Obtain the electric mobile application apk package, and determine the target intent field in the exposed component and the data type received by the exposed component based on the apk package; generate this round of test cases based on the target intent field using null values ​​and boundary values ​​of the data type, wherein this round of test cases contains multiple test cases; send this round of test cases for testing to determine whether a vulnerability is detected, and if a vulnerability is detected, stop testing and record the vulnerability information; if no vulnerability is detected, determine whether each test case in this round of test cases is received based on whether the log changes, and if the test case is not received, discard the test case; if the test case is received, calculate the fitness of the test case based on the execution time; based on the fitness of multiple test cases, screen and cross-mutate multiple test cases to generate the next round of test cases; use the next round of test cases as the test cases of this round, execute the steps of sending this round of test cases to determine whether a vulnerability is detected, and if no vulnerability is detected, determine whether it is received, and if it is received, calculate the fitness of each test case in this round of test cases and generate the next round of test cases until the number of iterations reaches the upper limit.

[0120] Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments, which will not be described in detail in this embodiment.

[0121] Optionally, in this embodiment, the storage medium may include, but is not limited to, various media that can store program codes, such as a USB flash drive, a ROM, a RAM, a mobile hard disk, a magnetic disk, or an optical disk.

[0122] According to another aspect of an embodiment of the present invention, a computer program product or computer program is also provided, which includes computer instructions, and the computer instructions are stored in a computer-readable storage medium; a processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the steps of the power mobile application vulnerability detection method in any of the above embodiments.

[0123] The serial numbers of the above embodiments of the present invention are for description only and do not represent the advantages or disadvantages of the embodiments.

[0124] If the integrated units in the above embodiments are implemented in the form of software functional units and sold or used as independent products, they can be stored in the above-mentioned computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling one or more computer devices (which can be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the power mobile application vulnerability detection method of each embodiment of the present invention.

[0125] In the above embodiments of the present invention, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0126] In the several embodiments provided herein, it should be understood that the disclosed client can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is merely a logical functional division. Actual implementations may employ other divisions, such as combining or integrating multiple units or components into another system, or omitting or disabling certain features. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through interfaces, or indirect coupling or communication connection between units or modules, either electrical or otherwise.

[0127] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected based on actual needs to achieve the purpose of the solution provided in this embodiment.

[0128] In addition, the functional units in the various embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0129] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as within the scope of protection of the present invention.

Claims

1. A method for detecting vulnerabilities in power mobile applications, characterized in that: The power mobile application vulnerability detection method includes: Obtain the electric mobile application APK package, and determine the target intent field in the exposed component and the data type received by the exposed component according to the APK package; Generate a current round of test cases based on the target intent field using a null value and a boundary value of the data type, wherein the current round of test cases includes multiple test cases; Send the test case of this round for testing to determine whether a vulnerability is detected. If a vulnerability is detected, stop the test and record the vulnerability information; If no vulnerability is detected, whether each test case in the current round of test cases is accepted is determined based on whether the log changes. If the test case is not accepted, the test case is discarded; If the test case is received, the fitness of the test case is calculated based on the execution time; Screening and cross-mutating the multiple test cases according to their fitness to generate the next round of test cases; The next round of test cases is used as the test cases of the current round, and the test cases of the current round are sent to determine whether a vulnerability is detected. If no vulnerability is detected, determine whether it is received. If it is received, calculate the fitness of each test case in the current round of test cases and generate the test cases of the next round until the number of iterations reaches the upper limit; Calculating the fitness of the test case according to the execution time includes: The fitness function is determined according to the timestamp in the log of changes corresponding to the test case. The fitness function formula is as follows: Where, T n is the last time the log changes after the test case is executed, T o The time when the test case starts executing.

2. The power mobile application vulnerability detection method according to claim 1, characterized in that: The step of screening and cross-mutating the multiple test cases according to their fitness to generate the next round of test cases includes: The test case with the largest fitness value among the multiple test cases is directly used as one of the test cases in the next round; Using a roulette wheel selection method to screen the test cases other than the test case with the largest fitness value among the multiple test cases to obtain a target test case; A cross operation is performed on the target test case according to the field value, and a mutation operation is performed on the target test case according to the data type to generate the next round of test cases.

3. The power mobile application vulnerability detection method according to claim 2, characterized in that: The performing a cross operation on the target test case according to the field value and the performing a mutation operation on the target test case according to the data type include: Swap the Data and Extra fields in any two target test cases; Randomly mutate the host, port, and path fields in the Data field of the intent according to the scheme field type; Mutate the Extra field in the intent according to the data type.

4. The power mobile application vulnerability detection method according to claim 3 is characterized in that: The mutating of the Extra field in the intent according to the data type includes: Mutate the data types allowed by the program into other types, mutate the values ​​of numeric type data, mutate the characters of character type data into character values ​​of different types, randomly mutate string type data according to field type, and mutate array type data according to array element value and array length.

5. The power mobile application vulnerability detection method according to claim 1, characterized in that: The obtaining of the electric mobile application APK package and determining, according to the APK package, a target intent field in an exposed component and a data type received by the exposed component include: Decompiling the electric mobile application APK package to obtain program source code and configuration files; Determine an exposed component and a path of the exposed component according to the configuration file, and obtain a program source code corresponding to the exposed component according to the program source code, the exposed component, and the path of the exposed component; The target intent field in the exposed component and the data type received by the exposed component are determined according to the program source code corresponding to the exposed component.

6. A power mobile application vulnerability detection device, characterized in that: The device comprises: a determination module, configured to obtain the electric mobile application APK package, and determine, based on the APK package, a target intent field in the exposed component and a data type received by the exposed component; A generating module, configured to generate a current round of test cases for the target intent field based on a null value and a boundary value of the data type, wherein the current round of test cases includes a plurality of test cases; A first judgment module is used to send the test case of the current round for testing, determine whether a vulnerability is detected, and if a vulnerability is detected, stop the test and record the vulnerability information; A second judgment module is configured to determine whether each test case in the current round of test cases has been accepted based on whether the log has changed if no vulnerability is detected, and discard the test case if the test case has not been accepted; A fitness calculation module, configured to calculate the fitness of a test case according to an execution time if a test case is received; A cross-mutation module is used to screen and cross-mutate multiple test cases according to their fitness, and generate test cases for the next round; An iteration module is configured to use the next round of test cases as the current round of test cases, execute the sending of the current round of test cases, determine whether a vulnerability is detected, and if no vulnerability is detected, determine whether it is received, and if it is received, calculate the fitness of each test case in the current round of test cases and generate the next round of test cases until the number of iterations reaches an upper limit; Calculating the fitness of the test case according to the execution time includes: The fitness function is determined according to the timestamp in the log of changes corresponding to the test case. The fitness function formula is as follows: Where, T n is the last time the log changes after the test case is executed, T o The time when the test case starts executing.

7. An electronic device comprising a processor, a communication interface, a memory and a communication bus, wherein: The processor, the communication interface and the memory communicate with each other via the communication bus, wherein: The memory is used to store computer programs; The processor is configured to execute the method steps according to any one of claims 1 to 5 by running the computer program stored in the memory.

8. A computer-readable storage medium, characterized in that: The storage medium stores a computer program, wherein the computer program implements the method steps described in any one of claims 1 to 5 when executed by a processor.

Images