Application program detection method, device, electronic device and storage medium

Abstract

The present application provides an application detection method, device, electronic device and storage medium. Among them, the application detection method includes: using a script injected into the process of the target Android program to monitor the functions called in the target Android program, and obtain the information to be detected in the process, and the information to be detected includes the attribute information of each called function; using the script, the risk coefficient of the function is calculated according to the information to be detected, and whether the target Android program has a risk problem according to the risk coefficient. The method uses a script to monitor the function called by the target Android program, obtains the information to be detected of the process, and then judges whether the target Android program has a risk problem according to the information to be detected, thereby realizing the detection of application risk problems. The method provides a dynamic detection method to avoid privacy and compliance issues in applications.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to an application detection method, device, electronic device and storage medium. Background Art

[0002] With the development of network technology, the risk of applications has attracted more and more attention, and personal information protection has become a global trend. Regulatory authorities have also strengthened personal information protection actions and introduced relevant laws and regulations. If an application violates laws and regulations, it will be removed from the shelves or unable to be listed.

[0003] Therefore, before an application is put on the shelves, it is necessary to detect risk issues on the application to ensure that the application does not have risk issues before it can be put on the shelves. The existing application detection method mainly matches the program code through keywords, but the accuracy of this method in discovering risk issues needs to be improved. Summary of the invention

[0004] The purpose of the embodiments of the present application is to provide an application detection method, device, electronic device and storage medium to solve the above technical problems.

[0005] To achieve the above objectives, this application provides the following technical solutions:

[0006] In a first aspect, an embodiment of the present application provides an application detection method, comprising: using a script injected into a process of a target Android program to monitor functions called in the target Android program, and obtaining information to be detected of the process, wherein the information to be detected includes attribute information of each called function; using the script to calculate a risk coefficient of the function based on the information to be detected, and judging whether the target Android program has a risk problem based on the risk coefficient.

[0007] During the running process of the target Android program, the above method uses a script injected into the process of the target Android program to monitor the function and obtain the information to be detected in the process, which includes the attribute information of each called function. The script can be used to calculate the risk coefficient of the function according to the information to be detected, thereby realizing the risk problem detection of the target Android program. The method provides a script detection and calculation risk method, which significantly improves the detection efficiency through script injection, avoids the risk of program code leakage, and is easy to use.

[0008] In an implementation of the first aspect, the method of using the script to calculate the risk coefficient of the function according to the information to be detected includes: using the script to group the functions according to preset calling rules and the information to be detected to obtain function groups that respectively satisfy each of the calling rules, and obtaining function groups that respectively satisfy each of the calling rules; calculating the risk coefficient of the function in each of the function groups according to the information to be detected, wherein the risk coefficient calculation methods of each of the function groups are different.

[0009] In the above implementation, by using the injected script, the called functions can be grouped according to the preset calling rules to obtain function groups that meet each calling rule. The calling rules may include, for example, concurrent calls, sensitive calls and other rules. The risk coefficient of each function under each function group can be calculated based on the information to be detected. The risk coefficient can be calculated as the ratio of the number of function calls to the number threshold, or directly as the number of calls. The risk coefficient calculation method of each function group is different, so that the risk coefficient of each function under each function group can be quickly calculated to reflect the risk problem.

[0010] In an implementation of the first aspect, the attribute information of the function includes at least one of the following: whether the target Android program is in the background state when the function is called; the name of the function; the start time of the function call; the execution time length of the function; and the stack information of the function itself.

[0011] In the above implementation, the information to be detected includes attribute information of each called function, which may include whether the target Android program is in the background when the function is called, the name, the start time of the call, the execution time length, and the stack information of the function itself, which can help to correctly group the functions to better complete the detection of risk issues. Developers can also rectify the risk issues existing in the functions within the group to better improve the code.

[0012] In an implementation of the first aspect, judging whether the target Android program has a risk problem based on the risk coefficient includes: determining whether the target Android program has a risk item based on the risk coefficient of the function in each function group and the risk coefficient threshold corresponding to the function group; wherein, if a risk item exists, it indicates that the target Android program has a risk problem, and if no risk item exists, it indicates that the target Android program does not have a risk problem.

[0013] In the above implementation, based on the risk coefficient of the function calculated in each function group and the risk threshold corresponding to the function group, it is possible to determine whether there are risk items in each group. The risk items can characterize the risk problems of the target Android program, so that the risk items can be rectified and the code can be improved.

[0014] In an implementation method of the first aspect, after determining whether the target Android program has risk items based on the risk coefficients of the functions in each function group and the risk coefficient thresholds corresponding to the function group, it includes: obtaining the weights of the risk items in the target Android program; calculating the risk value of the target Android program based on the weights of the risk items; and determining the risk level of the target Android program based on the risk value.

[0015] In the above implementation, after determining the risk items in the target Android program, the weight of each risk item can be obtained, and the risk value of the target Android program can be calculated according to the weight of the risk item, and finally the level of the current target Android program can be determined according to the risk value. The weight calculation of the risk item can accurately divide the level of the target Android program, and the developer can confirm the severity of the risk problem of the target Android program according to the level, as well as the manpower and time investment of the subsequent rectification project.

[0016] In an implementation of the first aspect, before monitoring the function using the script injected into the target Android program process, the method also includes: establishing a communication channel with the target Android program using the target interface provided by the Hook framework; and injecting the script into the process of the target Android program through the communication channel.

[0017] In the above implementation, the Hook framework can provide a target interface for establishing a communication channel with the target Android program, so that the script can be quickly injected into the process using the communication channel to monitor the function.

[0018] In an implementation of the first aspect, the method further includes: collecting statistics on calculation results of risk coefficients of the functions in each function group, and generating a risk report for the target Android program.

[0019] In the above implementation, the calculation results of the risk coefficient of each function in each function group can also be counted to generate a risk report. The risk report can provide an intuitive display of the calculation results of the risk coefficient of all functions, which is helpful for developers to clearly identify risk issues and make improvements.

[0020] In a second aspect, an embodiment of the present application provides an application detection method, comprising: using a script injected into the process of a target Android program to monitor functions called in the target Android program, and obtaining information to be detected of the process, wherein the information to be detected includes attribute information of each called function; obtaining the process number of the target Android program; sending the process number and the information to be detected to a server, so that the server calculates the risk coefficient of the function based on the information to be detected, and determines whether the target Android program has a risk problem based on the risk coefficient.

[0021] During the running process of the target Android program, after obtaining the information to be detected in the process, the above method obtains the process ID of the target Android program, and then sends the process ID and the information to be detected to the server. The server can use the process ID to distinguish the currently detected application, and can judge whether the target Android program has risk problems based on the information to be detected. This provides a risk detection method for the target Android program on the server side, reduces the difficulty of script writing, and only needs to complete the reporting process of the information to be detected in the script.

[0022] In the third aspect, an embodiment of the present application provides an application detection method, comprising: after the target iOS program is started, monitoring sensitive functions through a dynamic library pre-injected into the target iOS program, and obtaining information to be detected related to the sensitive functions; determining whether the target iOS program has risk issues based on the information to be detected.

[0023] After the target iOS program is started, the above method monitors sensitive functions through pre-injected dynamic libraries. Sensitive functions are functions related to privacy compliance issues in the application, and then obtains the information to be detected related to the sensitive functions, and determines whether there are risk issues in the target iOS program based on the information to be detected. The pre-injected dynamic library is used to detect risk issues during the operation of the application, and the dynamic detection of risk issues is realized, thereby improving the detection accuracy of risk issues.

[0024] In an implementation of the third aspect, the sensitive function includes a first-class function involving sensitive permissions, the first-class function is an Objective-C function, the information to be detected includes stack information, and the sensitive function is monitored by a dynamic library pre-injected into the target iOS program, and the information to be detected related to the sensitive function is obtained, including: using the dynamic library to dynamically change the correspondence between the method number and the method implementation of the first-class function when the first-class function is called, and pointing the method implementation of the first-class function to the corresponding first-class replacement function in the dynamic library; executing the first-class replacement function, and the first-class replacement function outputs its own stack information when executed.

[0025] In the above implementation, the first type of function involving sensitive permissions is the Objective-C language function in the iOS application, so it is necessary to monitor the first type of function. The monitoring method is to dynamically change the correspondence between the method number and the method implementation during the calling process of the first type of function, and output the stack information of the called first type of function, thereby achieving accurate detection of sensitive permission functions and reducing the false alarm rate.

[0026] In an implementation of the third aspect, the sensitive function includes a second type of function involving hardware information acquisition, the second type of function is a C function, the information to be detected includes stack information, and the sensitive function is monitored by a dynamic library pre-injected into the target iOS program, and the information to be detected related to the sensitive function is obtained, including: using the dynamic library to scan a MachO file to obtain a symbol table, and modifying the pointer of the function symbol in the symbol table so that the pointer of the function symbol of the second type of function points to a corresponding second type of replacement function in the dynamic library, wherein the MachO file is an executable file corresponding to the target iOS program; executing the second type of replacement function, and the second type of replacement function outputs its own stack information when executed.

[0027] In the above implementation, the second type of function involved in hardware information acquisition is a C language function, so it is necessary to monitor the second type of function running in the iOS application. By using the dynamic library to scan the MachO file, the pointer pointing in the symbol table obtained by the scan can be modified, thereby realizing the monitoring of the second type of function involved in hardware information acquisition. It can also achieve accurate detection of some hardware information acquisition functions that are not easy to find in iOS applications, thereby improving the detection accuracy of risk issues.

[0028] In an implementation of the third aspect, the sensitive function includes a network request function, and the information to be detected also includes a network request. The sensitive function is monitored through a dynamic library pre-injected into the target iOS program, and the information to be detected related to the sensitive function is obtained, including: monitoring the network request function through the dynamic library, and obtaining the network request to be sent by the network request function.

[0029] In the above implementation, the dynamic library can be used to monitor the network request function, so as to obtain the network request in the network request function. By detecting the network request, it is possible to timely discover the privacy information carried in the network request to avoid privacy leakage.

[0030] In an implementation of the third aspect, after obtaining the information to be detected related to the sensitive function, the method further includes: using the dynamic library to add a label to the stack information, wherein the label is used to identify the category of the sensitive function in the stack information.

[0031] In the above implementation, a dynamic library can be used to add a label to the stack information to distinguish the categories of sensitive functions in the stack information, so as to facilitate viewing of the stack information.

[0032] In an implementation of the third aspect, determining whether the target iOS program has a risk problem based on the detection information includes: obtaining the pre-configured level and weight of the sensitive function; determining the risk coefficient of the target iOS program based on the information to be detected, the level and weight of the sensitive function; and determining whether the target iOS program has a risk problem based on the risk coefficient.

[0033] In the above implementation, by obtaining the levels and weights of pre-configured sensitive functions, the called sensitive functions can be counted according to the stack information and network request information in the information to be detected, and the risk coefficient of the target iOS program can be calculated by the level and weight. Finally, the risk coefficient is used to determine whether there is a risk problem in the target iOS program. Therefore, the risk problem can be determined more accurately by calculating the risk coefficient, thereby avoiding the risk of the target iOS program not meeting the compliance requirements of the regulatory authorities and facing the risk of being removed from the shelves or prohibited from being listed.

[0034] In a fourth aspect, an embodiment of the present application provides an application detection method, comprising: after a target iOS program is started, monitoring sensitive functions through a dynamic library pre-injected into the target iOS program, and obtaining information to be detected related to the sensitive functions; using the dynamic library to generate a device ID and a process ID, the device ID is used to identify the electronic device running the target iOS program, and the process ID is used to identify the process where the target iOS program is located; sending the device ID, the process ID and the information to be detected to a server, so that the server determines whether there is a risk problem with the target iOS program based on the information to be detected.

[0035] After the target iOS program is started, the above method can generate a device ID and a process ID using a dynamic library to distinguish the currently detected electronic device and the target iOS program, and then send these related information to the server, so that the server can detect multiple devices and multiple applications at the same time, distinguish the ownership of the information to be detected, and complete the detection of application risk issues, making full use of the excellent performance of the server and achieving faster detection speed.

[0036] In a fifth aspect, an embodiment of the present application provides another application detection device, which includes: a monitoring module, which uses a script injected into the process of the target Android program to monitor the functions called in the target Android program, and obtain information to be detected of the process, wherein the information to be detected includes attribute information of each called function; a judgment module, which uses the script to calculate the risk coefficient of the function according to the information to be detected, and judge whether the target Android program has a risk problem according to the risk coefficient.

[0037] In a sixth aspect, an embodiment of the present application provides another application detection device, which includes: a monitoring module, which uses a script injected into the process of the target Android program to monitor the functions called in the target Android program, and obtain the information to be detected of the process, wherein the information to be detected includes attribute information of each called function; an acquisition module, which obtains the process number of the target Android program; and a sending module, which sends the process number and the information to be detected to a server, so that the server calculates the risk coefficient of the function based on the information to be detected, and determines whether the target Android program has a risk problem based on the risk coefficient.

[0038] In the seventh aspect, an embodiment of the present application provides another application detection device, which includes: a monitoring module, which is used to monitor sensitive functions through a dynamic library pre-injected into the target iOS program after the target iOS program is started, and obtain information to be detected related to the sensitive functions; a judgment module, which is used to determine whether the target iOS program has risk issues based on the information to be detected.

[0039] In an eighth aspect, an embodiment of the present application provides another application detection device, the device comprising: a monitoring module, for monitoring sensitive functions through a dynamic library pre-injected into the target iOS program after the target iOS program is started, and obtaining information to be detected related to the sensitive function; a generating module, for generating a device ID and a process ID using the dynamic library, the device ID being used to identify the electronic device running the target iOS program, and the process ID being used to identify the process where the target iOS program is located; a sending module, for sending the device ID, the process ID and the information to be detected to a server, so that the server determines whether the target iOS program has a risk problem based on the information to be detected.

[0040] In a ninth aspect, an embodiment of the present application provides an electronic device, comprising: a processor, a memory, and a bus, wherein the processor and the memory interact with each other through the bus;

[0041] The memory stores program instructions that can be executed by the processor, and the processor calls the program instructions to execute the method provided by the first to fourth aspects or any possible implementation of the first to fourth aspects.

[0042] In a tenth aspect, an embodiment of the present application provides a computer-readable storage medium, including:

[0043] The computer-readable storage medium stores computer instructions, and the computer instructions enable the computer to execute the method provided by the first to fourth aspects or any possible implementation manner of the first to fourth aspects.

[0044] In the eleventh aspect, an embodiment of the present application provides a computer program product, including computer program instructions, which, when read and executed by a processor, execute the method provided by the first to fourth aspects or any possible implementation of the first to fourth aspects.

[0045] Other features and advantages of the present application will be described in the following description, and partly become apparent from the description, or be understood by practicing the embodiments of the present application. The purpose and other advantages of the present application can be realized and obtained by the structures specifically pointed out in the written description, claims, and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments of the present application will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0047] Figure 1 A schematic diagram of the first application detection method provided in the embodiment of the present application;

[0048] Figure 2 A schematic diagram of a second application detection method flow chart provided in an embodiment of the present application;

[0049] Figure 3 A schematic diagram of a third application detection method flow provided in an embodiment of the present application;

[0050] Figure 4 A schematic diagram of a fourth application detection method flow provided in an embodiment of the present application;

[0051] Figure 5 A schematic diagram of a fifth application detection method flow chart provided in an embodiment of the present application;

[0052] Figure 6 A schematic diagram of the structure of a dynamic library provided in an embodiment of the present application;

[0053] Figure 7 A schematic diagram of a dynamic library injection method provided in an embodiment of the present application;

[0054] Figure 8 A schematic diagram of the structure of a first application detection device provided in an embodiment of the present application;

[0055] Fig. 9 A schematic diagram of the structure of a second application detection device provided in an embodiment of the present application;

[0056] Fig.10 A schematic diagram of the structure of a third application detection device provided in an embodiment of the present application;

[0057] Fig.11 A schematic diagram of the structure of a fourth application detection device provided in an embodiment of the present application;

[0058] Fig.12 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0059] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0060] In view of the problem that the accuracy of the existing method of detecting application risks by matching program codes with keywords needs to be improved, the present application provides an application detection method, which uses an executable function pre-injected into the target application to monitor the function called in the target application and obtain information to be detected related to the function; using the executable function, it is determined whether the target application has a risk problem based on the information to be detected. The executable function is an executable code pre-injected into the target application. For example, in an Android environment, the executable function can be a script, and in an iOS environment, the executable function can be a dynamic library. The method provides a dynamic detection method for a running target application, thereby improving the accuracy of risk detection, and simplifies the detection method of application risks by pre-injection.

[0061] The following describes the specific implementation methods of this application solution in the Android environment and the iOS environment respectively.

[0062] Embodiment 1

[0063] Figure 1 A schematic diagram of the first application detection method provided in the embodiment of the present application is shown in FIG. Figure 1 As shown, the method can be applied to an electronic device that can run an Android program; the electronic device can specifically be a smart phone, a tablet computer, a computer, a personal digital assistant (PDA), a server, a virtual machine, etc. Figure 1 , the method comprising:

[0064] Step 110: Use the script injected into the process of the target Android program to monitor the function called in the target Android program to obtain the information to be detected of the process.

[0065] Among them, the script can be a pre-designed Hook script, which is a script program written in some scripting language, which can hijack the function called in the application program, and execute the corresponding executable code in the Hook script after monitoring the function being called, so as to obtain the relevant attribute information of the function execution. Analyze the source code of Android framework Androidframework, Android reverse tool Jadx-Gui, etc., write the corresponding Hook script, and use Xpose, frida and other Hook frameworks to inject the Hook script. The Hook script can be written in Java, shell, JavaScript and other common scripting languages. This application does not limit the language type of the Hook script.

[0066] Taking a rooted mobile phone as an example, the script injection process is introduced. First, the mobile phone's Socket preset port A1 is started to establish a Socket communication channel with the PC. The PC sends the Hook script to the mobile phone, and then the mobile phone starts the Hook script to dynamically inject the Hook script into the process of the target Android program of the mobile phone. The script injection process is now completed.

[0067] The functions in step 110 can be divided into sensitive functions and ordinary functions. The Hook framework can monitor the global functions called by the target Android program by injecting scripts, including monitoring of sensitive functions and ordinary functions. Of course, sensitive functions can be focused on. In this embodiment, sensitive functions are defined as functions related to user information, such as functions for obtaining Macs, functions for obtaining camera permissions, etc., while ordinary functions are functions that are not related to user information, such as functions for obtaining WiFI names, functions for obtaining IP addresses, network request functions, etc.

[0068] The script can monitor functions through the Hook framework. For example, Xposed controls the Zygote process by replacing the / system / bin / app_process program in the Android application, so that the app_process will load the XposedBridge.jar jar package during the startup process, thereby completing the hijacking of the Zygote process and the Dalvik virtual machine it creates. The Hook of the function running in the process is completed when the computer is turned on, and the executable code in the script is added before and after the execution of the original function. During the startup process of the Zygote process, in addition to creating a Dalvik virtual machine instance, the Java runtime library will be loaded into the process, and some JNI methods of the Android core class will be registered to create the previous Dalvik virtual machine instance. It should be noted that when an application process is hatched by the Zygote process, it will not only obtain a copy of the Dalvik virtual machine instance in the Zygote process, but also share the Java runtime library with Zygote. This is why the XposedBridge jar package can be loaded into every Android application, realizing the Hook of the function called by the application, thereby completing the monitoring of the function.

[0069] The function monitoring process using frida can be as follows: a Hook script written in JavaScript is used to connect to the Native library of the target Android program using the target interface provided by frida, such as the js interface, so that some virtual machine interfaces can be obtained, such as the JNI (Java Native Interface) local function interface and the Java virtual machine interface. According to these virtual machine interfaces, the Hook script is packaged into a dynamic proxy object to hook the class corresponding to the corresponding function to complete the monitoring of the function.

[0070] Step 120: Utilize the script to calculate the risk factor of the function according to the information to be detected, and determine whether the target Android program has a risk problem according to the risk factor.

[0071] In some implementations, for example, the script can be used to group the functions in the detection information according to the preset calling rules. The calling rules can be the rules pre-set in the script. The function can be distinguished according to the calling method of the function to distinguish whether there is a risk problem. For example, the calling rules may include: concurrent calling, sensitive calling, unauthorized calling, silent background calling and background continuous calling. One or more. Concurrent calling means that the number of times the same function is called within one second exceeds the preset number threshold, sensitive calling means that the total number of times the same function is called exceeds the threshold, unauthorized calling means that the call is started before the privacy agreement and system permissions are agreed, or the time of the permission call exceeds the requested permission call time, silent background calling means that the number of calls to the function by the target Android program in the background state exceeds the threshold, and the background continuous calling means that the total time of the background call exceeds the time threshold within the preset time period. These thresholds are used to characterize the maximum value corresponding to the number of function calls within the preset time range executed by the script in the process of the target Android program, and the thresholds corresponding to different calling rules may be different. The preset time range for the execution of the script can be 10 minutes, 15 minutes, etc., and the size of the preset time range is not limited in this application.

[0072] If the current function meets a calling rule, it will be added to the function group of the calling rule. When the total number of calls or the number of calls per unit time of a function in the function group exceeds the threshold, the function will be treated as a risk item and needs to be rectified to avoid risk problems.

[0073] In some implementations, whether to add a function to a function group is determined by attribute information of the function included in the information to be detected, and the attribute information may include at least one of the following:

[0074] Whether the target Android program is in the background state when the function is called is a background attribute. During the grouping process, if the function has the background attribute, it is a background call. When continuous calls or unauthorized calls occur in the background, the function is added to the corresponding function group;

[0075] The name of the function is used as a means to locate the function, determine the start time and end time of the function call, and further determine the execution time length of the function and other attribute information.

[0076] By obtaining the attribute information of these functions, the grouping of each function can be clarified, so that the risk coefficient of the function belonging to each function group after grouping can be calculated more accurately according to the grouping situation.

[0077] In addition to the attribute information used to clarify the grouping of each function, the information to be detected also includes the stack information of the function itself, which is used to identify the call chain of the function in the target Android program and determine the calling relationship between the function and other functions. For example, for a function identified as a risk item, developers can view the stack information of the function itself to ultimately determine the problem of the function, so as to quickly locate the risk problem, make rectifications, and eliminate the risk problem of the target Android program.

[0078] The following is an introduction to the risk analysis of an Android program. For example, the pre-set function groups include sensitive function call groups, concurrent function call groups and background function call groups. The calling rules corresponding to the above function groups are matched, and then the functions are grouped and counted according to the attribute information of the functions recorded in the information to be detected, and the risk coefficient of each function in each group (function group) is calculated. The risk problem of the Android program is determined based on the risk coefficient. The existence of a risk item in any function group means that there is a risk problem.

[0079] Among them, when the function group is a sensitive function call group, follow the sensitive call rules introduced above, and use the ratio of the number of calls of the sensitive function to the call threshold as the risk coefficient of the sensitive function. First, determine the range of the sensitive function, and determine the sensitive function name that meets the sensitive function call rules and the statistical number of sensitive function calls based on the information to be detected. The ratio of the number of calls of each sensitive function and the corresponding call threshold is used as the risk coefficient. When obtaining the risk coefficient of each sensitive function, it is also necessary to compare it with the risk coefficient threshold of the sensitive function call group. If it is greater than, the sensitive function is recorded as a risk item, and the target Android program has a risk problem.

[0080] Among them, when the function group is a concurrent function call group, the concurrent call rules introduced above are followed. The concurrent call rules do not require sensitive functions, and ordinary functions are also included in the statistical scope. The function name that meets the background continuous call rules and the statistical number of concurrent calls of the function are determined according to the information to be detected. The statistical number is used as the risk coefficient of each function. If in the concurrent function call group, the number of concurrency, that is, the risk coefficient, exceeds the preset risk coefficient threshold, then the function is recorded as a risk item, and the target Android program has a risk problem.

[0081] For example, when the function group is a background continuous call, the above-mentioned background continuous call rules are followed. The function is not required to be a sensitive function in the background continuous call. First, the function name that meets the background continuous call rules and the statistical number of background continuous calls of the function are determined according to the information to be detected, and the ratio of the statistical number to the number threshold is used as the risk coefficient. If the risk coefficient of the function is greater than the risk coefficient threshold, the function is regarded as a risk item, and the target Android program has a risk problem.

[0082] It should be noted that different function groups may include the same function, but the calling rules of the function are different. Each function group is used to identify the calling rules of the function in the target Android program. The risk coefficient corresponding to the function can be calculated according to the risk coefficient calculation method corresponding to different function groups, and finally determine whether the function is a risk item.

[0083] In general, the calculation method of the risk coefficient of each function can be the ratio of the statistical number of each function in each function group and the preset number threshold, or the statistical number of each function in each function group. After calculating the risk coefficient, by comparing the risk coefficient with the risk coefficient threshold, it can be confirmed whether the function is a risk item, and then the risk problem can be determined.

[0084] In other implementations, the calculation results of the risk coefficients of the called functions in each function group can also be counted to generate a risk report for the target Android program. The risk report intuitively displays the risk coefficient values ​​of each function, and the overall detection results of the target Android program can be evaluated through the risk report, and the functions with higher risk coefficient values ​​are rectified first to ensure that there are no risk issues in the application. The risk report also includes the risk status of some network request functions. For example, in the network request function, regular expressions are used to match and confirm whether the transmission content of the network request function carries user information such as mobile phone numbers and bank card numbers, etc., to achieve comprehensive detection of the application.

[0085] Embodiment 2

[0086] This application also provides an alternative solution: Figure 2 A schematic diagram of a second application detection method provided in an embodiment of the present application is shown in FIG. Figure 2 As shown, after the above step 110, step 120 is not performed, but the following steps are performed:

[0087] Step 130: Obtain the process ID of the target Android program;

[0088] Step 140: Send the process number and the information to be detected to the server, so that the server calculates the risk coefficient of the function according to the information to be detected, and determines whether the target Android program has a risk problem according to the risk coefficient.

[0089] The replacement scheme is Figure 1 The difference of the described scheme is that determining whether an application has a risk based on the information to be detected is not performed by the electronic device, but by the server. In order to achieve the determination of the risk of the application by the server, the electronic device should also report the process number to the server so that the server can locate the application according to the process number. Among them, the specific implementation method of the server calculating the risk coefficient of the function based on the information to be detected and judging whether the target Android program has a risk problem based on the risk coefficient can refer to the specific method of determining the risk of the application by the electronic device in Example 1, and will not be repeated here. In this embodiment, the risk detection of the target application in the electronic device by the server makes full use of the excellent processing performance of the server, which is more efficient and faster.

[0090] Embodiment 3

[0091] Figure 3 The third application detection method provided in the present application embodiment is a flow chart. According to the above description, the method can be a rooted Android phone, where the PC injects a script into the electronic device to detect the target Android program running in the electronic device. Figure 3 As shown, the method includes:

[0092] Step 310: The PC is connected to the mobile phone, the target Android program is started, and the script is injected into the electronic device.

[0093] For specific implementation methods, please refer to Figure 1 The script injection method in the corresponding embodiment has been described in detail above and will not be repeated here.

[0094] Step 320: Use the script to monitor the function and obtain the information to be detected.

[0095] The specific implementation method can be: by injecting a script, the information to be detected can be obtained, and the information to be detected includes the attribute information of each called function. The script can be used to obtain the stack and record the attribute information of the function. The recording method can first identify the function by the attribute information, and then group them according to the calling rules to obtain the function groups that meet each calling rule. For details, please refer to Figure 1 Introduction to attribute information and grouping in the corresponding embodiments.

[0096] Step 330: Perform calculations based on the information to be detected to obtain calculation results.

[0097] The specific implementation method can be: through the previous function grouping, the risk coefficient of each function in each group is calculated respectively, and the risk coefficient is compared with the corresponding risk threshold to determine whether there is a risk item. For details, please refer to Figure 1 The calculation of the risk factor in the corresponding embodiment.

[0098] Step 340: Generate a risk report based on the calculation results.

[0099] The specific implementation method can be: the risk report here includes the statistics of the risk coefficient calculation of each function in each function group. The risk report can also include the stack information of the specific function and the non-compliant network request, so as to facilitate developers to find risk items according to the risk report and obtain the root cause of the problem from the stack information according to the risk items, so as to speed up rectification and ensure that the target Android program can meet the requirements of the regulatory authorities and avoid the risk of being removed from the shelves.

[0100] Embodiment 4

[0101] Figure 4 A schematic diagram of a fourth application detection method flow provided in an embodiment of the present application is shown in FIG. Figure 4 As shown, the method can be applied to an electronic device that can run an iOS program; the electronic device can specifically be a smart phone, a tablet computer, a computer, a personal digital assistant (PDA), a server, a virtual machine, etc. Figure 4 , the method comprising:

[0102] Step 410: After the target iOS program is started, the sensitive function is monitored through the dynamic library pre-injected into the target iOS program, and the information to be detected related to the sensitive function is obtained.

[0103] For example, when the target iOS program is running, the system dynamically loads it into the memory for the program to call. The dynamic library is also called a dynamic link library. The extension of the dynamic library file in the iOS system can be ".dylib" or ".framework". In the solution of this application, by pre-injecting the dynamic library into the target iOS program, sensitive functions can be monitored, and the method of dynamically detecting the application program is used to improve the detection accuracy of risk issues.

[0104] After completing the pre-injection of the dynamic library, you can use the dynamic library to monitor the sensitive function calls that need to be monitored in the running target iOS program to complete the dynamic monitoring of the target iOS program. By monitoring the sensitive functions, you can obtain the information to be detected related to the sensitive functions.

[0105] According to the above description, in some implementations, for example, the sensitive functions involved in iOS applications can be roughly divided into the following two categories: the first category of functions involving sensitive permissions and the second category of functions involving hardware information acquisition. The first category of functions can be common sensitive permission functions of iOS applications, and the language type of these sensitive permission functions is Objective-C language type. For example, the 15 common sensitive permission functions in the iOS system include: access to media library permissions, access to Bluetooth permissions, access to calendar permissions, access to camera permissions, access to photo album permissions, access to address book permissions, access to FaceID / fingerprint permissions, access to health data permissions, access to health updates, access to residential accessories permissions, access to location information permissions, access to microphone permissions, access to reminder permissions, access to voice recognition / Siri permissions, and permission to use personalized advertising recommendation symbols. More permission functions can also be used as sensitive functions, and this application does not limit the types of sensitive permission functions.

[0106] By using the Runtime feature of the Objective-C language, the method implementation of the first-class function can be replaced. In order to obtain the information to be detected when the first-class function is called, the first-class function can be monitored, and the monitoring means can be to use the dynamic library to Hook the first-class function. For example, when the first-class function is called, the corresponding relationship between the method number and the method implementation of the first-class function is dynamically changed by using the dynamic library, and the method implementation of the first-class function is pointed to the corresponding first-class replacement function in the dynamic library, thereby dynamically changing the method implementation of the first-class function, and then executing the corresponding first-class replacement function in the dynamic library, and outputting its own stack information. It can be understood that for outputting its own stack information during execution, since the corresponding first-class replacement function in the dynamic library is the dynamic library code pointed to by the method implementation of the first-class function, it can reflect the function information of the first-class function, and the function information on the entire call chain involving the first-class function is output to the stack information, and the subsequent stack information about itself is also the same, and the relevant function information on the call chain will be output.

[0107] The second type of function may be a function in an iOS application that involves hardware information acquisition. The hardware information may include but is not limited to the number of CPU cores, CPU operating frequency, device mac address, device Bluetooth address, device ROM size, device RAM size, etc. The language type of the hardware information acquisition function is C language. MachO files are executable files on platforms such as Mac, iPhone, iPad, iWatch, and Apple TV. MachO is the abbreviation of Mach Object file format, which is the file format of executable files. Sensitive functions include the second type of functions involved in hardware information acquisition, so it is necessary to use a dynamic library to monitor the C language function for hardware information acquisition, so as to obtain the information to be detected related to hardware information acquisition.

[0108] The monitoring principle of the second type of function by the dynamic library can be as follows: the dynamic library can be used to scan the MachO file to obtain the symbol table, and the lazy loading symbol table in the MachO file corresponds one-to-one with the function symbol in the indirect symbol table. The indirect symbol table saves the offset of the function symbol in the symbol table, and each sub-item in the symbol table saves the offset of the function symbol in the string table.

[0109] The specific implementation method for monitoring the second type of function can be: find the function name corresponding to the function symbol through the offset of the string table; establish the correspondence between the function symbol and the function name; find the final function symbol address through the function name; modify the content of the function symbol to point to the corresponding second type replacement function in the dynamic library, and finally execute the second type replacement function to output its own stack information during execution. The stack information of itself has been explained above and will not be repeated here.

[0110] In some other implementations, the network request function may also cause risks due to privacy data leakage, so monitoring of the network request function is also included. The network request function may be, for example, a network request function that supports the HTTP / HTTPS protocol.

[0111] The specific method of monitoring the network request function is: first sort the NSURLSessionConfiguration session configuration items, and then inject the NSURLProtocol implemented by the dynamic library into the NSURLSessionConfiguration preferences. NSURLProtocol is the handle control class in NSURLConnection and NSURLSession, so network requests will be processed by the methods in NSURLProtocol, that is, monitor the upper-level URLRequest network request, and customize the response processing according to your own needs, and then you can monitor the network request function of the HTTP / HTTPS protocol. According to the requirements of the regulatory authorities, a sensitive information detection table is constructed, including but not limited to plain text mobile phone numbers, plain text ID numbers, IDFA and other information. Regular matching can be used to filter the sent network requests, and network requests with information leakage are stored in the information to be detected, so that network requests with sensitive information leakage can be determined.

[0112] Through the above three sensitive function monitoring methods, it is possible to implement multi-faceted monitoring of sensitive functions in the target iOS program, improve the detection rate of risk issues, and protect user privacy and security.

[0113] Step 420: Determine whether the target iOS program has any risk issues based on the information to be detected.

[0114] By obtaining the information to be detected related to sensitive functions, such as stack information or network requests, it is possible to determine whether the target iOS program has risk issues by checking whether the stack information contains sensitive functions or whether the request body of the network request contains private data. Risk issues can include privacy issues or compliance issues. For example, the camera permission function and the phone number permission function are both sensitive functions. When the information to be detected contains the stack information of these functions, and when the network request issued includes private content such as phone number or device information, it can be considered that there are risk issues.

[0115] In other implementations, dynamic libraries can also be used to label the stack information. The purpose of the label is to identify the category of sensitive functions in the stack information. The category can be, for example, the Chinese name corresponding to the sensitive function, such as obtaining the device number, to effectively distinguish the sensitive function. Stack information is used to temporarily store data and addresses. The dynamic library can be used to print the sensitive functions called by the system into the stack, but there may be multiple interfaces that call sensitive functions in the system. For example, the function that obtains camera permissions may be called by multiple interfaces in the application, which needs to be distinguished. There may also be multiple calls to privacy functions in one interface. By obtaining the stack information of sensitive function calls and labeling the stack information, sensitive functions can be identified. For example, in the stack information, all function call relationships on the call chain involving sensitive functions will be printed out, generally including function names, function addresses, and other information. The label can be marked with the Chinese name of the function we are familiar with. If the method of labeling sensitive functions is not adopted, it is difficult to quickly determine sensitive functions in these complex function call relationships. Therefore, by labeling sensitive functions, it is convenient for technicians to find sensitive functions in time and improve the efficiency of detection.

[0116] In some implementations, functions called by the target iOS program can be divided into sensitive functions and ordinary functions. The level of sensitive functions can be set to 1, and the level of ordinary functions can be set to 0. Alternatively, the level of sensitive functions can be further divided to distinguish the importance of different sensitive functions. The weight of a sensitive function is a (M, N) tuple, where M represents the time interval when the sensitive function is called, and N represents the upper limit of the number of times it is called within the time interval of M. The weight of the sensitive function can be determined by the values ​​of M and N in the tuple, and the risk coefficient of the target iOS program can be determined by using the information related to the sensitive function detected in the information to be detected. For example, when only one sensitive function is detected in the information to be detected, the risk coefficient of the sensitive function can be directly calculated as the risk coefficient of the target iOS program. When multiple sensitive functions are detected in the information to be detected, the risk coefficient corresponding to the target iOS program can be obtained by weighted calculation based on the level and weight of the acquired sensitive functions, and the risk coefficient can be used to determine whether the target iOS program has a risk problem. For example, the risk level of the target iOS program can be divided according to the risk coefficient, and the risk level of the target iOS program can be determined by the risk coefficient.

[0117] Embodiment 5

[0118] This application also provides an alternative solution: Figure 5 A fifth application detection method flow chart provided in the present application embodiment is as follows: Figure 5 As shown, after the above step 410, step 420 is not performed, but the following steps are performed:

[0119] Step 430: Generate a device ID and a process ID using a dynamic library, where the device ID is used to identify the electronic device running the target iOS program, and the process ID is used to identify the process where the target iOS program is located;

[0120] Step 440: Send the device ID, process ID and information to be detected to the server, so that the server can determine whether the target iOS program has risk issues based on the information to be detected.

[0121] The replacement scheme is Figure 4 The difference between the above schemes is that, the execution subject of the above step 420 can be a server connected to the iOS device, and the iOS device can also obtain its own device ID and the process ID of the target iOS program, and send the device ID, process ID and information to be detected to the server, so that the server can complete the judgment of the risk problem of the target iOS program, thereby realizing the risk detection of the target iOS program in the iOS device by the server, making full use of the excellent processing performance of the server, with higher efficiency and faster detection. The specific implementation method of determining whether the target iOS program has a risk problem based on the information to be detected can refer to the present application and Figure 4 The methods provided in the corresponding embodiments will not be described in detail here.

[0122] Embodiment 6

[0123] Figure 6 The following is a schematic diagram of the structure of a dynamic library provided in the embodiment of the present application. According to the above description, the dynamic library is a callable shared function library. The dynamic library can be divided into the following modules according to the functions, which are used to implement different functions respectively. The dynamic library plays a role by being dynamically loaded into the target iOS program of the above method embodiment. Figure 6 As shown, the dynamic library 600 includes an initialization module 610, a data reporting module 620, a data storage module 630, a dynamic library link Hook module 640, a network request Hook module 650, a sensitive permission Hook module 660 and a sensitive function Hook module 670. The embodiment of the present application provides a dynamic library, which includes:

[0124] The initialization module 610 is used to generate a device ID and a process ID, initialize the log, configure the level and weight of sensitive functions, configure sensitive permission labels, configure hardware information acquisition function labels, and configure network request sensitive data labels.

[0125] Among them, after the dynamic library is loaded into the target iOS program in the above method embodiment, the device ID and process ID are generated through the initialization module 610 to realize the sending of the information to be detected. The operation log can also be generated to record the operation status of the dynamic library. Through the level, weight and label configuration of the sensitive function, the processing of the information to be detected can be realized, which is convenient for technical personnel to view and determine the program risks.

[0126] The logic for generating the unique device ID is as follows: obtain the saved UDID from the Keychain according to the Key. If obtained, put the UDID into the storage module for subsequent data upload. Otherwise, generate a random UDID; store the UDID in the Keychain.

[0127] The data reporting module 620 is used to obtain the version and name of the application, obtain the reporting address, and report the stack information and network request.

[0128] A specific implementation method may be: after the dynamic library is dynamically injected into the target iOS program of the above method embodiment, the IP address reported by the information and the application name and version number information of the target iOS program are obtained, and the latest data information is obtained from the data storage module 630 at regular intervals and reported to the specified IP address, thereby realizing the collection of the information to be detected in the server.

[0129] The data storage module 630 is used to store stack information and network requests, and to establish a Redis cache for real-time data storage.

[0130] The specific implementation method can be: using the singleton mode and the data structures of NSDictionary and NSArray to realize the Redis function, which can quickly cache the detected stack information or network request data, and using the data storage module 630 to realize the storage function of the information to be detected in the above method embodiment to prevent information loss.

[0131] The dynamic library link Hook module 640 is used to scan the MachO file, obtain the symbol table, and rebind the function symbols in the symbol table.

[0132] For specific implementation, please refer to the above Figure 4 The method embodiment relates to a monitoring method of the second type of function for obtaining hardware information.

[0133] The network request Hook module 650 is used to obtain network requests involving sensitive information by monitoring network request functions.

[0134] For specific implementation, please refer to Figure 4The embodiment involves an implementation method of monitoring a network request function, and puts the network request with information leakage into the data storage module 630, waiting for the data reporting module 620 to upload.

[0135] The sensitive permission Hook module 660 is used to monitor the sensitive permission function and call the data storage module 630 to store the stack information related to the sensitive permission function. Figure 4 The embodiment involves an implementation method for monitoring the first type of functions of sensitive permission functions.

[0136] The sensitive function Hook module 670 is used to monitor the hardware information acquisition function and call the data storage module 630 to store the stack information of the hardware information acquisition function. Figure 4 The embodiment relates to an implementation method of the second type of function monitoring for obtaining hardware information.

[0137] Embodiment 7

[0138] Figure 7 A flow chart of a dynamic library injection method provided in an embodiment of the present application is applied to an iOS device, which can be a normal iOS device without jailbreaking, such as Figure 7 As shown, the dynamic library injection process can be divided into three processes: compilation, injection, and running.

[0139] First, after the coding of the dynamic library system is completed, the dynamic library is compiled through the compilation tool Xcode. The purpose of compilation is to convert the code of the dynamic library into an executable binary file, so as to inject it into the target iOS program. The specific compilation process includes: preprocessing the macro definitions in the code; semantic and grammatical analysis, abstract syntax tree conversion; static analysis of the syntax tree, including type checking, implementation checking, and variable calling; generating LLVM compiler code; optimizing the intermediate code generated by LLVM IR compilation in the optimization stage; generating the executable file of the dynamic library.

[0140] Secondly, after the compilation is completed, the generated dynamic library is injected. The specific implementation method of injection is as follows: read the MachO file data stream; traverse the MachO file data stream, find the last LoadCommand loader command, and record the offset; determine whether the offset position can open up the corresponding injection space, and terminate if the injection space is insufficient; read the injected dynamic library file information according to the offset, and generate the corresponding LoadCommand; fill the binary data of LoadCommand to the specified position of the MachO file; write the new MachO file data stream into the file of the target iOS program.

[0141] Finally, after the injection is completed, the target iOS program is started. The specific implementation method of the operation is as follows: install the Xcode application on a computer running MacOS; after Xcode is installed, inject the dynamic library into the IPA installation package that needs to be detected through Xcode, which is the installation package corresponding to the target iOS program and repackages it; re-sign the repackaged IPA file; then install the re-signed IPA file to the iOS device through Xcode; and start the installed target iOS program.

[0142] Embodiment 8

[0143] Figure 8 This is a schematic diagram of the structure of the first application detection device provided in the embodiment of the present application. The device may be a module, program segment or code on an electronic device. It should be understood that the device is similar to the above-mentioned Figure 1 The method embodiment corresponds to and can be executed Figure 1 The various steps involved in the method embodiment and the specific functions of the device can be found in the above description. To avoid repetition, detailed description is appropriately omitted here. The present application embodiment provides an application detection device, which includes:

[0144] A monitoring module 810 is used to monitor the functions called in the target Android program by using the script injected into the process of the target Android program, and obtain the information to be detected of the process, wherein the information to be detected includes the attribute information of each called function;

[0145] The judgment module 820 is used to use the script to calculate the risk coefficient of the function according to the information to be detected, and judge whether the target Android program has a risk problem according to the risk coefficient.

[0146] Based on the above embodiment, the determination module 820 is specifically used for:

[0147] Using the script, grouping the functions according to preset calling rules and the information to be detected, to obtain function groups that respectively meet the calling rules;

[0148] The risk coefficient of the function in each of the function groups is calculated according to the information to be detected, wherein the risk coefficient calculation methods of each of the function groups are different.

[0149] Based on the above embodiment, the attribute information of the function includes at least one of the following:

[0150] Whether the target Android program is in the background state when the function is called;

[0151] the name of the function;

[0152] The calling start time of the function;

[0153] the length of time the function takes to execute; and,

[0154] The stack trace of the function itself.

[0155] Based on the above embodiment, the determination module 820 is specifically used for:

[0156] Determine whether the target Android program has a risk item according to the risk coefficient of the function in each function group and the risk coefficient threshold corresponding to the function group;

[0157] If there is a risk item, it indicates that the target Android program has a risk problem, and if there is no risk item, it indicates that the target Android program does not have a risk problem.

[0158] Based on the above embodiment, the device further includes a risk level determination module, which is used to:

[0159] Obtaining the weight of the risk item in the target Android program;

[0160] Calculating the risk value of the target Android program according to the weight of the risk item;

[0161] The risk level of the target Android program is determined according to the risk value.

[0162] Based on the above embodiment, the device further includes an injection module, which is used to:

[0163] Use the target interface provided by the Hook framework to establish a communication channel with the target Android program;

[0164] The script is injected into the process of the target Android program through the communication channel.

[0165] Based on the above embodiment, the device further includes a risk report generating module, which is used to:

[0166] The calculation results of the risk coefficients of the functions in each function group are counted to generate a risk report of the target Android program.

[0167] Embodiment 9

[0168] Fig. 9 This is a schematic diagram of the structure of the second application detection device provided in the embodiment of the present application. The device may be a module, program segment or code on an electronic device. It should be understood that the device is similar to the above-mentioned Figure 2The method embodiment corresponds to and can be executed Figure 2 The various steps involved in the method embodiment and the specific functions of the device can be found in the above description. To avoid repetition, detailed description is appropriately omitted here. The present application embodiment provides another application detection device, which includes:

[0169] A monitoring module 910 is used to monitor the functions called in the target Android program by using the script injected into the process of the target Android program, and obtain the information to be detected of the process, wherein the information to be detected includes the attribute information of each called function;

[0170] The acquisition module 920 is used to obtain the process ID of the target Android program;

[0171] The sending module 930 is used to send the process number and the information to be detected to the server, so that the server calculates the risk coefficient of the function according to the information to be detected, and determines whether the target Android program has a risk problem according to the risk coefficient.

[0172] Embodiment 10

[0173] Fig.10 The third application detection device provided in the embodiment of the present application is a schematic diagram of the structure of the device, which can be a module, program segment or code on an electronic device. It should be understood that the device is similar to the above Figure 4 The method embodiment corresponds to and can be executed Figure 4 The various steps involved in the method embodiment and the specific functions of the device can be found in the above description. To avoid repetition, detailed description is appropriately omitted here. The present application embodiment provides another application detection device, which includes:

[0174] The monitoring module 1010 is used to monitor the sensitive function through the dynamic library pre-injected into the target iOS program after the target iOS program is started, and obtain the to-be-detected information related to the sensitive function;

[0175] The judgment module 1020 is used to determine whether the target iOS program has a risk problem according to the information to be detected.

[0176] Based on the above embodiment, the sensitive function includes a first type of function involving sensitive permissions, the first type of function is an Objective-C function, and the information to be detected includes stack information.

[0177] Based on the above embodiment, the monitoring module 810 is specifically used for:

[0178] Using the dynamic library to dynamically change the correspondence between the method number and the method implementation of the first class function when the first class function is called, and point the method implementation of the first class function to the corresponding first class replacement function in the dynamic library;

[0179] The first-type replacement function is executed, and the first-type replacement function outputs its own stack information when executed.

[0180] Based on the above embodiment, the sensitive function includes a second type of function involving hardware information, the second type of function is a C function, and the information to be detected includes stack information.

[0181] Based on the above embodiment, the monitoring module 1010 is specifically used for:

[0182] Scanning a MachO file using the dynamic library to obtain a symbol table, and modifying the pointer pointing to the function symbol in the symbol table so that the pointer of the function symbol of the second class function points to the corresponding second class replacement function in the dynamic library, wherein the MachO file is an executable file corresponding to the target iOS program;

[0183] The second-type replacement function is executed, and the second-type replacement function outputs its own stack information when executed.

[0184] Based on the above embodiment, the sensitive function includes a network request function, and the information to be detected also includes a network request.

[0185] Based on the above embodiment, the sensitive function includes a network request function, and the information to be detected also includes a network request.

[0186] Based on the above embodiment, the monitoring module 1010 is specifically used for:

[0187] The network request function is monitored using the dynamic library, and the network request to be sent by the network request function is obtained.

[0188] Based on the above embodiment, the device further includes a label module, which is used to:

[0189] The dynamic library is used to add a label to the stack information, where the label is used to identify the category of the sensitive function in the stack information.

[0190] Based on the above embodiment, the determination module 1020 is specifically used for:

[0191] Obtaining the pre-configured level and weight of the sensitive function;

[0192] Determine the risk factor of the target iOS program according to the information to be detected, the level and weight of the sensitive function;

[0193] Determine whether the target iOS program has a risk problem based on the risk factor.

[0194] Embodiment 11

[0195] Fig.11 This is a schematic diagram of the structure of the fourth application detection device provided in the embodiment of the present application. The device may be a module, program segment or code on an electronic device. It should be understood that the device is similar to the above-mentioned Figure 5 The method embodiment corresponds to and can be executed Figure 5 The various steps involved in the method embodiment and the specific functions of the device can be found in the above description. To avoid repetition, detailed description is appropriately omitted here. The present application embodiment provides another application detection device, which includes:

[0196] The monitoring module 1110 is used to monitor the sensitive function through the dynamic library pre-injected into the target iOS program after the target iOS program is started, and obtain the to-be-detected information related to the sensitive function;

[0197] A generating module 1120, configured to generate a device ID and a process ID using the dynamic library, wherein the device ID is used to identify the electronic device running the target iOS program, and the process ID is used to identify the process where the target iOS program is located;

[0198] The sending module 1130 is used to send the device ID, the process ID and the information to be detected to the server, so that the server determines whether the target iOS program has a risk problem according to the information to be detected.

[0199] Embodiment 12

[0200] Fig.12 FIG. 1 shows a possible structure of the electronic device 1200 provided in an embodiment of the present application. Fig.12 The electronic device 1200 includes: a processor 1210, a memory 1220 and a communication interface 1230. These components are interconnected and communicate with each other through a communication bus 1240 and / or other forms of connection mechanisms (not shown).

[0201] The memory 1220 includes one or more (only one is shown in the figure), which may be, but not limited to, a random access memory (RAM), a read only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), etc. The processor 1210 and other possible components may access the memory 1220 and read and / or write data therein.

[0202] The processor 1210 includes one or more (only one is shown in the figure), which can be an integrated circuit chip with signal processing capabilities. The above-mentioned processor 1210 can be a general-purpose processor, including a central processing unit (CPU), a micro control unit (MCU), a network processor (NP) or other conventional processors; it can also be a special-purpose processor, including a graphics processing unit (GPU), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components.

[0203] The communication interface 1230 includes one or more (only one is shown in the figure), which can be used to communicate directly or indirectly with other devices to exchange data. The communication interface 1230 can include an interface for wired and / or wireless communication.

[0204] One or more computer program instructions may be stored in the memory 1220 , and the processor 1210 may read and execute these computer program instructions to implement the application detection method and other desired functions provided in the embodiments of the present application.

[0205] Understandably, Fig.12 The structure shown is for illustration only. The electronic device 1200 may also include Fig.12 More or fewer components as shown, or with Fig.12 Different configurations shown. Fig.12 The components shown in the figure can be implemented by hardware, software or a combination thereof. The electronic device 1200 may be a physical device, such as a PC, a laptop, a tablet computer, a mobile phone, a server, an embedded device, etc., or a virtual device, such as a virtual machine, a virtualized container, etc. Moreover, the electronic device 1200 is not limited to a single device, but may also be a combination of multiple devices or a cluster consisting of a large number of devices.

[0206] The present application also provides a computer-readable storage medium on which computer program instructions are stored. When the computer program instructions are read and executed by a computer processor, the application detection method provided by the present application is executed. For example, the computer-readable storage medium can be implemented as Fig.12 The memory 1220 in the electronic device 1200.

[0207] An embodiment of the present application also provides a computer program product, which includes computer program instructions. When these computer program instructions are read and executed by a processor, the application detection method provided by the embodiment of the present application is executed.

[0208] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or interactive connection shown or discussed can be through some interactive interfaces, and the indirect coupling or interactive connection of devices or units can be electrical, mechanical or other forms.

[0209] In addition, the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0210] Furthermore, the functional modules in the various embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.

[0211] In this document, relational terms such as first and second, etc. are used merely to distinguish one entity or operation from another entity or operation, but do not necessarily require or imply any such actual relationship or order between these entities or operations.

[0212] The above description is only an embodiment of the present application and is not intended to limit the protection scope of the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. An application detection method, characterized in that: include: Using a script injected into the process of the target Android program, the functions called in the target Android program are monitored to obtain the information to be detected of the process; wherein the information to be detected is used to characterize the function calling behavior and program status information when the program is running, and the information to be detected includes the attribute information of each called function; Using the script, calculating the risk coefficient of the function according to the information to be detected, and judging whether the target Android program has a risk problem according to the risk coefficient; The step of using the script to calculate the risk coefficient of the function according to the information to be detected includes: Using the script, grouping the functions according to preset calling rules and the information to be detected, to obtain function groups that respectively meet the calling rules; The risk coefficient of the function in each of the function groups is calculated according to the information to be detected, wherein the risk coefficient calculation methods of each of the function groups are different.

2. The method according to claim 1, characterized in that The attribute information of the function includes at least one of the following: Whether the target Android program is in the background state when the function is called; the name of the function; The calling start time of the function; the length of time the function takes to execute; and, The stack trace of the function itself.

3. The method according to claim 1, characterized in that The determining, according to the risk coefficient, whether the target Android program has a risk problem includes: Determine whether the target Android program has a risk item according to the risk coefficient of the function in each function group and the risk coefficient threshold corresponding to the function group; If there is a risk item, it indicates that the target Android program has a risk problem, and if there is no risk item, it indicates that the target Android program does not have a risk problem.

4. The method according to claim 3, characterized in that After determining whether the target Android program has a risk item according to the risk coefficient of the function in each function group and the risk coefficient threshold corresponding to the function group, the method includes: Obtaining the weight of the risk item in the target Android program; Calculating the risk value of the target Android program according to the weight of the risk item; The risk level of the target Android program is determined according to the risk value.

5. The method according to claim 1, characterized in that Before monitoring the function called in the target Android program by using the script injected into the target Android program process, the method further includes: Use the target interface provided by the Hook framework to establish a communication channel with the target Android program; The script is injected into the process of the target Android program through the communication channel.

6. An application detection method, characterized in that: include: Using the script injected into the process of the target Android program to monitor the function called in the target Android program, and obtain the information to be detected of the process; The information to be detected is used to characterize the function calling behavior and program status information when the program is running, and the information to be detected includes the attribute information of each called function; Get the process ID of the target Android program; Sending the process number and the information to be detected to the server, so that the server calculates the risk coefficient of the function according to the information to be detected, and determines whether the target Android program has a risk problem according to the risk coefficient; The step of calculating the risk coefficient of the function according to the information to be detected includes: The functions are grouped according to preset calling rules and the information to be detected to obtain function groups that respectively meet the calling rules; The risk coefficient of the function in each of the function groups is calculated according to the information to be detected, wherein the risk coefficient calculation methods of each of the function groups are different.

7. An application detection method, characterized in that: include: After the target iOS program is started, the sensitive function is monitored through the dynamic library pre-injected into the target iOS program, and the to-be-detected information related to the sensitive function is obtained; wherein the to-be-detected information is used to characterize the calling behavior of the function and the program status information when the program is running; Determine whether the target iOS program has a risk problem according to the information to be detected; Determining whether the target iOS program has a risk problem according to the detection information includes: Obtaining the pre-configured level and weight of the sensitive function; Determine the risk factor of the target iOS program according to the information to be detected, the level and weight of the sensitive function; Determine whether the target iOS program has a risk problem based on the risk factor.

8. The method according to claim 7, characterized in that The sensitive function includes a first type of function involving sensitive permissions, the first type of function is an Objective-C function, the information to be detected includes stack information, and the sensitive function is monitored by a dynamic library pre-injected into the target iOS program, and the information to be detected related to the sensitive function is obtained, including: Using the dynamic library to dynamically change the correspondence between the method number and the method implementation of the first class function when the first class function is called, and point the method implementation of the first class function to the corresponding first class replacement function in the dynamic library; The first-type replacement function is executed, and the first-type replacement function outputs its own stack information when executed.

9. The method according to claim 7, characterized in that: The sensitive function includes a second type of function related to hardware information acquisition, the second type of function is a C function, the information to be detected includes stack information, and the sensitive function is monitored by a dynamic library pre-injected into the target iOS program, and the information to be detected related to the sensitive function is obtained, including: Scanning a MachO file using the dynamic library to obtain a symbol table, and modifying the pointer pointing to the function symbol in the symbol table so that the pointer of the function symbol of the second class function points to the corresponding second class replacement function in the dynamic library, wherein the MachO file is an executable file corresponding to the target iOS program; The second-type replacement function is executed, and the second-type replacement function outputs its own stack information when executed.

10. The method according to claim 7, characterized in that The sensitive function includes a network request function, the information to be detected also includes a network request, and the sensitive function is monitored by a dynamic library pre-injected into the target iOS program, and the information to be detected related to the sensitive function is obtained, including: The network request function is monitored using the dynamic library, and the network request to be sent by the network request function is obtained.

11. The method according to claim 8 or 9, characterized in that: After obtaining the information to be detected related to the sensitive function, the method further includes: The dynamic library is used to add a label to the stack information, where the label is used to identify the category of the sensitive function in the stack information.

12. An application detection method, characterized in that: include: After the target iOS program is started, the sensitive function is monitored through the dynamic library pre-injected into the target iOS program, and the information to be detected related to the sensitive function is obtained; wherein the information to be detected is used to characterize the function call behavior and program status information when the program is running; Generate a device ID and a process ID using the dynamic library, wherein the device ID is used to identify the electronic device running the target iOS program, and the process ID is used to identify the process where the target iOS program is located; Sending the device ID, the process ID, and the information to be detected to a server, so that the server determines whether the target iOS program has a risk problem according to the information to be detected; Determining whether the target iOS program has a risk problem according to the detection information includes: Obtaining the pre-configured level and weight of the sensitive function; Determine the risk factor of the target iOS program according to the information to be detected, the level and weight of the sensitive function; Determine whether the target iOS program has a risk problem based on the risk factor.

13. An application detection device, characterized in that: include: A monitoring module, used to monitor the functions called in the target Android program by using the script injected into the process of the target Android program, and obtain the information to be detected of the process; the information to be detected is used to characterize the function calling behavior and program status information when the program is running, and the information to be detected includes the attribute information of each called function; A judgment module, used to use the script to calculate the risk coefficient of the function according to the information to be detected, and judge whether the target Android program has a risk problem according to the risk coefficient; The judgment module is specifically used for: Using the script, grouping the functions according to preset calling rules and the information to be detected, to obtain function groups that respectively meet the calling rules; The risk coefficient of the function in each of the function groups is calculated according to the information to be detected, wherein the risk coefficient calculation methods of each of the function groups are different.

14. An application detection device, characterized in that: include: A monitoring module, used for monitoring sensitive functions through a dynamic library pre-injected into the target iOS program after the target iOS program is started, and obtaining information to be detected related to the sensitive function; wherein the information to be detected is used to characterize the function call behavior and program status information when the program is running; A judgment module, used for determining whether the target iOS program has a risk problem according to the information to be detected; The judgment module is specifically used for: Obtaining the pre-configured level and weight of the sensitive function; Determine the risk factor of the target iOS program according to the information to be detected, the level and weight of the sensitive function; Determine whether the target iOS program has a risk problem based on the risk factor.

15. An electronic device, characterized in that: include: processor, memory and bus, wherein, The processor and the memory communicate with each other via the bus; The memory stores program instructions executable by the processor, and the processor can execute the method according to any one of claims 1 to 12 by calling the program instructions.

16. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and when the computer instructions are executed by a computer, the computer is caused to perform the method according to any one of claims 1 to 12.

Images