Third-party SDK behavior detection method, device, medium and electronic device

By running the application to be detected in the mimic behavior honeypot, and analyzing its calling stack information, the target behavior generated by the third -party SDK is determined, and the problem of the lack of effective third -party SDK behavior detection methods in existing technology has been solved. The precise detection and safety improvement of third -party SDK behavior.

CN112231697BActive Publication Date: 2025-01-24TENCENT TECHNOLOGY (SHENZHEN) CO LTD
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
CN202011223482.9
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2020-11-05
Publication Date
2025-01-24
Estimated Expiration
2040-11-05

AI Technical Summary

Technical Problem

The lack of effective third-party SDK behavior detection methods in the prior art has led to users lacking a clear understanding of the integrated third-party SDK and posing security risks.

Method used

By obtaining the application to be detected that contains the target third-party SDK, and running the application in the simulator behavior honeypot, according to the set behavioral characteristics of the target behavior, obtain the calls when the target behavior occurs from the application's running log Stack information determines the code block that is called when the target behavior is generated. If the code block belongs to the code block of the target third-party SDK, it is determined that the target behavior is generated by the target third-party SDK.

Benefits of technology

The detection of specific third -party SDK behaviors is achieved, reducing potential risks and improving the security of the APP use process.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN112231697B_ABST
    Figure CN112231697B_ABST
Patent Text Reader

Abstract

The present application provides a method, device, medium and electronic device for detecting the behavior of a third-party SDK, and relates to the fields of computer technology and software. In this method, by obtaining an application to be detected that contains a target third-party SDK, and running the application to be detected in a simulator behavior honeypot, the call stack information when the target behavior occurs is obtained from the running log of the application to be detected according to the set behavior characteristics of the target behavior, so as to determine the code block called when the target behavior is generated according to the obtained call stack information, and if the called code block belongs to the code block of the target third-party SDK, it is determined that the target behavior is generated by the target third-party SDK. This method can detect the behavior of a specific third-party SDK, reduce potential risks, and improve the security of the APP use process.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, device, medium and electronic device for detecting third-party SDK behavior. Background Art

[0002] At present, the use of third-party SDKs (Software Development Kits) is very common. An officially launched APP generally integrates about 20 third-party SDKs. While third-party SDKs are widely used, their related security issues are also receiving increasing attention. Insecure network communications will lead to user privacy leaks.

[0003] There is a lack of effective countermeasures for third-party SDK behavior detection. Users, including APP developers, lack a clear understanding of the integrated third-party SDKs, leaving security risks.

[0004] How to provide a third-party SDK behavior detection method to detect the behavior of specific third-party SDKs and improve the security of APP use is a hot issue that needs to be solved. Summary of the invention

[0005] The embodiments of the present application provide a method, device, medium and electronic device for detecting the behavior of a third-party SDK, so as to detect the behavior of a specific third-party SDK and improve the security of the APP use process.

[0006] To achieve the above purpose, the technical solution of the embodiment of the present application is implemented as follows:

[0007] In a first aspect, an embodiment of the present application provides a method for detecting third-party SDK behavior, including:

[0008] Obtain an application to be detected that includes a target third-party software development kit SDK, and run the application to be detected in a simulator behavior honeypot;

[0009] According to the behavior characteristics of the set target behavior, obtaining the call stack information when the target behavior occurs from the running log of the application to be detected;

[0010] According to the acquired call stack information, determine the code block that is called when the target behavior is generated;

[0011] If the called code block belongs to the code block of the target third-party SDK, it is determined that the target behavior is generated by the target third-party SDK.

[0012] In a second aspect, an embodiment of the present application provides a third-party SDK behavior detection device, including:

[0013] A simulation operation unit, used for obtaining an application to be detected including a target third-party software development kit SDK, and running the application to be detected in a simulator behavior honeypot;

[0014] The behavior detection unit is used to obtain the call stack information when the target behavior occurs from the running log of the application to be detected according to the behavior characteristics of the set target behavior; determine the code block that is called when the target behavior is generated according to the obtained call stack information; if the called code block belongs to the code block of the target third-party SDK, determine that the target behavior is generated by the target third-party SDK.

[0015] In an optional embodiment, the simulation operation unit is specifically used to: for each candidate application, decompile the program package file of the candidate application to obtain the code package of the candidate application;

[0016] Code segmentation is performed on the code package of the candidate application to obtain code blocks included in the candidate application.

[0017] In an optional embodiment, the behavior detection unit is specifically used for:

[0018] Acquire a call chain from the call stack information; the call chain includes function information of multiple call points;

[0019] Removing function information of a call point associated with a system function from the call chain;

[0020] The code block that is called when the target behavior is generated is determined according to the function information of the remaining call points in the call chain.

[0021] In a third aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method described in any one of the first aspects is implemented.

[0022] In a fourth aspect, an embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program that can be run on the processor, and when the computer program is executed by the processor, the processor implements any method described in the first aspect.

[0023] The third-party SDK behavior detection method, device, medium and electronic device of the embodiment of the present application obtains the application to be detected containing the target third-party SDK, and runs the application to be detected in the simulator behavior honeypot, and then obtains the call stack information when the target behavior occurs from the running log of the application to be detected according to the set behavior characteristics of the target behavior, thereby determining the code block called when the target behavior is generated according to the acquired call stack information, and if the called code block belongs to the code block of the target third-party SDK, it is determined that the target behavior is generated by the target third-party SDK. Since the simulator behavior honeypot is used in the embodiment of the present application to simulate the operation of the application to be detected containing the target third-party SDK, detect the generated target behavior, and then determine the target behavior belonging to the third-party SDK by back-tracing the call stack information, this method can detect the behavior of a specific third-party SDK, reduce potential risks, and improve the security of the APP use process. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0025] Figure 1 A schematic diagram of the framework structure of a simulator behavior honeypot provided in an embodiment of the present application;

[0026] Figure 2 A flowchart of a method for detecting third-party SDK behavior provided in an embodiment of the present application;

[0027] Figure 3 A schematic diagram of call stack information provided in an embodiment of the present application;

[0028] Figure 4 A schematic diagram of a process for obtaining an application to be detected provided in an embodiment of the present application;

[0029] Figure 5 A flowchart of a code segmentation process provided in an embodiment of the present application;

[0030] Figure 6 A schematic diagram of a flow chart of determining a code block to be called when a target behavior is generated provided in an embodiment of the present application;

[0031] Figure 7 A schematic diagram of a system framework provided for an embodiment of the present application;

[0032] Figure 8 A schematic diagram of the structure of a third-party SDK behavior detection device provided in an embodiment of the present application;

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

[0034] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present application.

[0035] It should be noted that the terms "including" and "having" and their variations involved in the documents of this application are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0036] Some of the terms used in the embodiments of the present application are explained below to facilitate understanding by those skilled in the art.

[0037] (1) SDK: A collection of documents, examples, and tools that assist in developing APPs (Applications, mobile application software). On the Android platform, APP developers can outsource certain functions to a third party to improve development efficiency and reduce costs. The third-party service provider encapsulates the service into a toolkit (SDK) for APP developers to use. Currently, common SDK types include third-party login sharing, payment, push, advertising, and data statistics and analysis.

[0038] (2) APK (Android application package): an application package file format used by the Android operating system to distribute and install mobile applications and middleware. If an Android application code wants to run on an Android device, it must first be compiled and then packaged into a file that can be recognized by the Android system before it can be run. The file format that can be recognized and run by the Android system is "APK". An APK file contains compiled code files (.dex files), file resources (resources), native resource files (assets), certificates (certificates), and a manifest file (manifest file). In the embodiments of the present application, the example of the candidate application program package file being an APK file is used for explanation.

[0039] (3) Call stack backtracing: Hook the API functions that generate sensitive behaviors in Android applications. When these key functions are called, obtain and record their call stack information in the Java virtual machine. Then, find the call points of these key functions by backtracing the call stack information.

[0040] (4) API (Application Programming Interface): some predefined functions. In addition to coordinating the execution of applications, memory allocation, and system resource management, the operating system is also a large service center. Calling various services of this service center (each service is a function) can help applications open windows, draw graphics, and use peripheral devices. The application program interface is: "the code provided by the 'computer operating system' or 'program library' for application programs to call and use." Its main purpose is to allow application developers to call a set of routine functions without having to consider the underlying source code or understand the details of its internal working mechanism. The API itself is abstract. It only defines an interface and does not involve the specific operations of the application in the actual implementation process.

[0041] (5) Hook: Also known as the hook function, it is a platform for the operating system's message processing mechanism. Applications can set up subroutines on it to detect certain messages from a specified window, and the detected window can be created by other processes. When a message arrives, it is processed before the target window processing function. The hook mechanism allows applications to intercept and process operating system messages or specific events. Hooks can detect various event messages in the system or process, intercept messages sent to the target window and process them. A hook is actually a program segment that processes messages, which is hung into the system through a system call. Whenever a specific message is sent, before it reaches the destination window, the hook program captures the message first, that is, the hook function gets control first. A hook has an associated pointer list, called the hook list, which is maintained by the system. The pointers in this list point to the specified, application-defined callback functions called by the hook subroutine, that is, the various processing subroutines of the hook. When a message associated with a specified hook type occurs, the system passes the message to the hook subroutine. Some Hook sub-routines can only detect messages, or modify messages, or stop the advancement of messages to prevent these messages from being delivered to the next Hook sub-routines or destination windows.

[0042] (6) Behavioral honeypot: Honeypot technology is essentially a technology for deceiving attackers. By placing some hosts, network services or information as bait, the attackers are lured to attack them, so that the attack behavior can be captured and analyzed, the tools and methods used by the attackers can be understood, and the attack intentions and motives can be inferred. This allows the defender to clearly understand the security threats they face, and enhance the security protection capabilities of the actual system through technical and management means. In the embodiments of the present application, a simulator behavioral honeypot can be set according to the honeypot technology to simulate the execution of applications integrated with a specific third-party SDK.

[0043] The word “exemplary” is used hereinafter to mean “serving as an example, example, or illustration.” Any embodiment described as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.

[0044] The terms "first" and "second" in this document are used for descriptive purposes only and should not be understood as explicitly or implicitly indicating relative importance or implicitly indicating the number of technical features indicated. Therefore, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features, and in the description of the embodiments of this application, unless otherwise specified, the meaning of "plurality" is two or more.

[0045] With the development of mobile Internet and the widespread use of smart mobile terminals, the security of smart phones has become the most concerned issue for the mobile Internet industry and mobile Internet users. In the rapid development of mobile Internet, with the gradual expansion of the number and scale of developers, many SDK tools and middlewares have been derived to provide developers with various services, such as SDK middlewares that provide advertising promotion services, SDK middlewares that provide message and data push, and SDK middlewares that provide application promotion and distribution, etc. These SDK middlewares provide developers with various commonly used functions through the form of open development interfaces, which greatly facilitates developers. At present, the use of third-party SDKs under the Android platform is very common. An officially launched APP generally integrates about 20 third-party SDKs. While third-party SDKs are widely used, their related security issues are also receiving increasing attention. Insecure network communication will lead to user privacy leakage. For example, third-party SDKs may have security vulnerabilities themselves and steal user privacy data without permission, and some malicious SDKs use APPs to perform malicious operations. Some third-party SDKs also have hot update functions, which can dynamically send code from the cloud for execution during operation. This situation causes users, including APP developers, to have no clear understanding of the specific execution behavior of the integrated third-party SDK, thus posing security risks.

[0046] In terms of third-party SDK behavior detection, existing solutions are mainly based on static code analysis and lack effective countermeasures. How to provide a third-party SDK behavior detection method to detect the behavior of specific third-party SDKs and improve the security of APP use is an urgent problem that needs to be solved.

[0047] In the embodiment of the present application, by obtaining an application to be detected that includes a target third-party SDK, and running the application to be detected in a simulator behavior honeypot, the call stack information when the target behavior occurs is obtained from the running log of the application to be detected according to the behavioral characteristics of the set target behavior, and then the code block called when the target behavior is generated is determined based on the obtained call stack information. If the called code block belongs to the code block of the target third-party SDK, it is determined that the target behavior is generated by the target third-party SDK. Since the simulator behavior honeypot is used in the embodiment of the present application to simulate the operation of the application to be detected that includes the target third-party SDK, the generated target behavior is detected, and then the target behavior belonging to the third-party SDK is determined by back-tracing the call stack information. This method can detect the behavior of a specific third-party SDK, reduce potential risks, and improve the security of the APP use process.

[0048] To further illustrate the technical solution provided by the embodiment of the present application, a detailed description is given below in conjunction with the accompanying drawings and specific implementation methods. In the embodiment of the present application, the application to be detected is an APP under the Android platform; the target behavior is a sensitive behavior that needs to be detected when the APP is running. Although the embodiment of the present application provides the method operation steps shown in the following embodiments or drawings, more or fewer operation steps may be included in the following method based on routine or no creative labor. In the steps where there is no necessary causal relationship logically, the execution order of these steps is not limited to the execution order provided by the embodiment of the present application. In the actual processing process or when the device is executed, the following method can be executed in the method sequence shown in the embodiment or drawings or in parallel.

[0049] Figure 1 A schematic diagram of the framework structure of a simulator behavior honeypot provided in an embodiment of the present application is shown.

[0050] like Figure 1 As shown, the simulator honeypot mainly consists of the following parts:

[0051] 1. Hook module, used to hook the function specified by the application to obtain its related parameters, execution results, etc.;

[0052] 2. Automatic trigger module, used to automatically run the APP and trigger the APP's behavior as much as possible;

[0053] 3. Sensitive behavior detection point module, which is used to set sensitive behaviors that need to be detected, such as network access, sub-package loading, command execution, elf file access, etc.

[0054] 4. The LOG recording module is used to log the execution information of sensitive behaviors and the call stack information when sensitive behaviors occur. The LOG recording module can be divided into two sub-modules: behavior LOG and call stack LOG.

[0055] In the embodiment of the present application, the honeypot technology is used to set Figure 1 The simulator behavior honeypot shown simulates the execution of an application integrated with a target third-party SDK to capture the behavior information of the application, thereby detecting sensitive behaviors generated by the application.

[0056] Figure 2 FIG. 1 is a flow chart showing a method for detecting a third-party SDK behavior provided by an embodiment of the present application. Figure 2 As shown, the method comprises the following steps:

[0057] Step S201, obtaining an application to be detected that includes a target third-party SDK.

[0058] The target third-party SDK may be a pre-specified third-party SDK that is expected to be detected. The number of target third-party SDKs and the number of applications to be detected may be one or more. In the embodiment of the present application, the number of target third-party SDKs and the number of applications to be detected are both one as an example. For example, the application to be detected may be an application APP under the Android platform. i , the target third-party SDK can be an application APP i Package file APK i Included third-party software development kit SDK j The third-party SDK behavior detection method provided in the embodiment of the present application first obtains the target third-party software development kit SDK j APPs to be tested i .

[0059] Step S202: running the application to be detected in the simulator behavior honeypot.

[0060] Specifically, in Figure 1 The simulator behavior shown is running the application to be tested in the honeypot i The Hook module of the simulator behavior honeypot sets the application to be detected APP iHook the specified function to obtain its related parameters, execution results, etc. The automatic trigger module of the simulator behavior honeypot can automatically run the application APP to be detected i , and trigger the APP as much as possible i The sensitive behavior detection point module of the simulator behavior honeypot sets the behavior characteristics of the target behavior that needs to be detected, such as network access, sub-package loading, command execution, elf file access, etc. The LOG recording module of the simulator behavior honeypot outputs the execution information of the target behavior and the call stack information when the target behavior occurs, wherein the target behavior is a sensitive behavior determined according to the set behavior characteristics of the target behavior; for example, obtaining the user's private information, linking to illegal websites, etc. In some embodiments, the target behavior is part of the sensitive behavior. In other embodiments, the target behavior is all of the sensitive behavior. The embodiments of the present application are all described by taking the target behavior as all of the sensitive behavior as an example.

[0061] Step S203, according to the set behavior characteristics of the target behavior, obtain the call stack information when the target behavior occurs from the running log of the application to be detected.

[0062] The behavior characteristics of the target behavior are behavior characteristics set in the simulator behavior honeypot for selecting the target behavior to be detected. The behavior characteristics of the target behavior can be behavior characteristics set for the application to be detected and used for data acquisition. The behavior characteristics of the target behavior include but are not limited to network access, sub-package loading, command execution, elf file access, etc.

[0063] Specifically, according to the behavioral characteristics of the set target behavior, from the application APP to be detected i Get the call stack information when the target behavior occurs in the running log. The call stack information contains the call chain when the target behavior occurs.

[0064] Exemplarily, obtaining the call stack information when the target behavior occurs may be obtaining a Figure 3 A call chain is shown.

[0065] Step S204: determining the code block that is called when the target behavior is generated according to the acquired call stack information.

[0066] Specifically, for the acquired call stack information, relevant system functions in the call chain are removed to acquire the function information of the actual call point of the call chain, and the code block called when the target behavior is generated is determined according to the function information of the actual call point of the call chain.

[0067] For example, for Figure 3The call chain shown is searched from front to back, and some system-related calls in the call chain are removed, such as java.net and com.android.okhttp related calls in the call chain, and the function information of the actual call point of the call chain is obtained as com.tencent.msdk.dns.core.aaab (HttpDnsImpl.java:53). In some embodiments, the code block called when the target behavior occurs can be determined based on the prefix of the class name of the function information of the actual call point of the call chain.

[0068] Step S205: if the called code block belongs to the code block of the target third-party SDK, it is determined that the target behavior is generated by the target third-party SDK.

[0069] For example, if the target third-party SDK is com.tencent.msdk, for Figure 3 In the call chain shown, if it is determined that the called code block belongs to the code block of com.tencent.msdk, it is determined that the target behavior is generated by the target third-party SDK.

[0070] The above-mentioned method for detecting third-party SDK behavior obtains the application to be detected that includes the target third-party SDK, and runs the application to be detected in the simulator behavior honeypot, and then obtains the call stack information when the target behavior occurs from the running log of the application to be detected according to the set behavior characteristics of the target behavior, so that the code block called when the target behavior is generated can be determined based on the obtained call stack information. If the called code block belongs to the code block of the target third-party SDK, it is determined that the target behavior is generated by the target third-party SDK. Since the simulator behavior honeypot is used in the embodiment of the present application to simulate the operation of the application to be detected including the target third-party SDK, the generated target behavior is detected, and then the target behavior belonging to the third-party SDK is determined by back-tracing the call stack information. This method can detect the behavior of a specific third-party SDK, reduce potential risks, and improve the security of the APP use process.

[0071] In an embodiment of the present application, the application to be detected that includes the target third-party SDK can be obtained by code segmentation and third-party SDK identification. The following is a further description of how to obtain the application to be detected that includes the target third-party SDK by code segmentation and third-party SDK identification. Figure 4 As shown, obtaining the application to be tested that contains the target third-party SDK includes the following steps:

[0072] Step S401 , code segmentation is performed on the program package file of the candidate application to obtain various code blocks included in the candidate application.

[0073] In some embodiments, candidate applications can be selected one by one to perform code splitting in step S401 of this embodiment. For each selected candidate application, the code segmentation is performed until it is identified whether the annotation information of each code block in the selected candidate application contains the target SDK annotation information, and then the next candidate application is selected.

[0074] Specifically, first, a candidate application is obtained, and then code segmentation is performed on the obtained program package file of the candidate application to obtain various code blocks contained in the candidate application.

[0075] In some embodiments, the candidate applications may be multiple Android application programs APP, and the package files of the candidate applications may be Android application package APK files. Specifically, the package files of the candidate applications are decompiled by dex, for example, the decompiled object is APK. 1 , APK 2 、…、APK n , obtain the decompiled smali code package. Then, the decompiled code package is segmented according to the specified segmentation rule to obtain the code blocks contained in each APK file, such as code block 1, code block 2, ..., code block m. Optionally, the specified segmentation rule can be the storage path of the decompiled smali code package.

[0076] Step S402: according to the ownership relationship between each code block and the third-party SDK, SDK annotation information is set for each code block, where the SDK annotation information is used to identify the third-party SDK to which the code block belongs.

[0077] Extract basic information of the obtained code block, such as the path name of the code block, opcode simhash value, number of classes, number of methods, called API set, tree structure of code block code organization, etc.

[0078] In some embodiments, by comparing and analyzing the code of the code block, it is possible to identify which third-party SDK each code block belongs to and manually mark it, thereby obtaining the attribution relationship between the code block and the third-party SDK. Then, based on the attribution relationship between the code block and the third-party SDK, a code block data sample set of the attribution relationship between the code block and the third-party SDK can be established, and the code block data sample set includes a label of the code block, and the label can be SDK annotation information set for each code block, and the SDK annotation information is used to identify the third-party SDK to which the code block belongs.

[0079] In some other embodiments, the code block data sample set established by manual marking can also be combined, and the new code block obtained by code segmentation of the program package file of the candidate application can be identified by clustering the code block to identify the ownership relationship between the code block and the third-party SDK. Then the ownership relationship obtained according to the cluster analysis is added to the code block data sample set for storage. Specifically, the cluster analysis can be based on part of the information in the basic information of the code block, for example, a Key value is generated according to the path name and opcode simhash in the basic information of the code block, so that each code block has a unique Key value. For each code block in the code block data sample set, a Key value corresponding to the code block is also generated. Cluster analysis is performed on each code block according to the Key value to obtain the ownership relationship between the code block and the third-party SDK.

[0080] The code block data sample set can also be regarded as a label system, which can also include other information of the code block, such as the function and type of the code block. According to the code block data sample set, it can be determined which third-party SDKs the Android application APP contains.

[0081] Step S403, determine whether the annotation information of each code block in the candidate application contains the target SDK annotation information. If yes, execute step S404; if not, return to execute step S401.

[0082] Step S404: determine the candidate application as the application to be detected.

[0083] When the annotation information of each code block in the candidate application includes the target SDK annotation information, the candidate application is determined as the application to be detected.

[0084] Specifically, if the annotation information of a code block in a specific candidate application contains the target SDK annotation information, it can be determined that the annotation information of each code block in the candidate application contains the target SDK annotation information, and the candidate application is determined as the application to be detected. Based on this, the application to be detected in the candidate application can be determined, and the application to be detected can be one or more, and this application does not make specific restrictions on this.

[0085] The above-mentioned method for detecting third-party SDK behaviors is to obtain the various code blocks contained in the candidate application by code segmentation of the program package file of the candidate application; SDK annotation information is set for each code block according to the ownership relationship between each code block and the third-party SDK, and the SDK annotation information is used to identify the third-party SDK to which the code block belongs; when the annotation information of each code block in the candidate application contains the target SDK annotation information, the candidate application is determined as the application to be detected. Since code block segmentation and third-party SDK identification are used in the embodiment of the present application, the granularity of the detection of third-party SDK behaviors is refined to the third-party SDK. This method can detect the behavior of specific third-party SDKs, reduce potential risks, and improve the security of the APP use process. In the case of increasingly frequent use of third-party SDKs and frequent security issues, this detection method helps us to more clearly analyze the APP with malicious behaviors, whether the initiator of the specific malicious or sensitive behavior is the APP developer itself or the third-party SDK integrated by it, and determine the division of responsibilities.

[0086] In some other embodiments, when obtaining the application to be detected that contains the target third-party SDK through code segmentation and third-party SDK identification, the candidate applications can be selected one by one to perform Figure 4 The code segmentation of step S401 in step 402 is performed until all candidate applications have completed code segmentation, and then all candidate applications are sequentially executed. Figure 4 Other process steps after step S401.

[0087] In some optional embodiments, the called code block belongs to the code block of the target third-party SDK, which can be determined by the following method:

[0088] When the SDK annotation information of the called code block is consistent with the SDK annotation information of the code block of the target third-party SDK, it is determined that the called code block belongs to the code block of the target third-party SDK.

[0089] In some embodiments, the code block data sample set includes a correspondence between a target third-party SDK and a code block to which the target third-party SDK belongs, and annotation information of the code block to which the target third-party SDK belongs.

[0090] Specifically, the SDK annotation information of the called code block is compared with the SDK annotation information of the target third-party SDK's code block. If the two are consistent, it can be determined that the called code block belongs to the target third-party SDK's code block.

[0091] Exemplarily, in combination with the code block data sample set, it can be determined whether the SDK annotation information of the called code block is consistent with the SDK annotation information of the target third-party SDK code block. When the SDK annotation information of the called code block is consistent with the SDK annotation information of the target third-party SDK code block, it is determined that the called code block belongs to the target third-party SDK code block.

[0092] The above-mentioned third-party SDK behavior detection method determines whether the SDK annotation information of the called code block is consistent with the SDK annotation information of the target third-party SDK code block, thereby determining that the called code block belongs to the target third-party SDK code block. Since this method uses the SDK annotation information of the called code block to compare with the SDK annotation information of the target third-party SDK code block, the calculation amount is small, which can improve the efficiency of third-party SDK behavior detection, thereby effectively reducing potential risks and improving the security of the APP use process.

[0093] Figure 5 FIG. 1 is a flow chart of a code segmentation process provided by an embodiment of the present application. In some optional embodiments, the program package file of the candidate application is code segmented, and when the code blocks contained in the candidate application are obtained, the program package file can be decompiled. Figure 5 As shown, the process of obtaining the code block may specifically include the following steps:

[0094] Step S501 : for each candidate application, decompile the program package file of the candidate application to obtain a code package of the candidate application.

[0095] For example, the candidate applications may be multiple Android application programs, such as APP 1 、APP 2 、…、APP n ; The package file of the candidate application can be an Android application package APK file, such as APK 1 , APK 2 、…、APK n Among them, APP 1 、APP 2 、…、APP n With APK 1 , APK 2 、…、APK n It is a one-to-one correspondence in order. For example, it can be a candidate application APP t , t∈(1,n) package file APK t , t∈(1,n), decompile to get the candidate application APP t The code package.

[0096] In some embodiments, decompilation of the package file is achieved by dex decompilation.

[0097] For example, decompile the candidate application APP through dex t Package file APK t , get the candidate application APP t The smali code package.

[0098] Step S502 , code segmentation is performed on the code package of the candidate application to obtain code blocks included in the candidate application.

[0099] Exemplarily, the code package of the candidate application may be code segmented according to a specified segmentation rule. For example, the smali code package may be code segmented according to the storage path of the smali code package, thereby obtaining the code blocks included in the candidate application.

[0100] In some optional embodiments, when determining the code block called when the target behavior is generated, the call chain can be first obtained according to the acquired call stack information, and then the call chain is processed and analyzed to determine the code block called when the target behavior is generated. Figure 6 As shown, the process may specifically include the following steps:

[0101] Step S601, obtaining a call chain from the call stack information.

[0102] The call chain includes function information of multiple call points.

[0103] Specifically, in the embodiment of the present application, a simulator behavior honeypot is used to detect the application APP i Perform simulated execution. The simulator behavior honeypot outputs the execution information of the sensitive behavior and the call stack information when the sensitive behavior occurs in the form of a LOG log according to the behavioral characteristics of the set target behavior. In some embodiments, the call stack information is obtained by parsing the LOG log output by the simulator behavior honeypot. The call stack information includes the call chain when the target behavior occurs. Each call chain corresponds to a sensitive behavior, and the call chain and the sensitive behavior are in a one-to-one correspondence. Figure 3 FIG. 1 shows a call chain of an embodiment of the present application. Figure 3 It can be seen that the call chain includes function information of multiple call points. The call chain is obtained from the call stack information by backtracing the call stack information. The obtained call chain is used in the analysis process of call stack backtracing.

[0104] Step S602: Remove the function information of the call point associated with the system function from the call chain.

[0105] For example, for Figure 3 The call chain shown is searched from front to back, and some system-related calls in the call chain are removed. For example, the calls related to java.net and com.android.okhttp in the call chain are removed. The function information of the remaining call points in the call chain is obtained as com.tencent.msdk.dns.core.aaab (HttpDnsImpl.java:53), which is the function information of the actual call point of the call chain.

[0106] Step S603, determining the code block that is called when the target behavior is generated according to the function information of the remaining call points in the call chain.

[0107] Specifically, the code block called when the target behavior occurs can be determined based on the prefix of the class name of the function information of the actual call point of the call chain. For example, when the function information is com.tencent.msdk.dns.core.aaab (HttpDnsImpl.java:53), the prefix information of the class name is com.tencent.msdk.dns.core.aaa, and combined with the record of the basic information of the code block in the code block data sample set, the code block called when the target behavior corresponding to the call chain is generated can be determined.

[0108] The above-mentioned third-party SDK behavior detection method determines the code block called when the target behavior corresponding to the call chain is generated by calling stack backtracing. Since this method uses the call stack backtracing method, it can accurately locate the code block that generates sensitive behavior, and thus accurately determine the third-party SDK that generates sensitive behavior, which can effectively reduce potential risks and improve the security of the APP use process.

[0109] Figure 7 A schematic diagram of the system framework of a third-party SDK behavior detection method provided in an embodiment of the present application. In one embodiment, Figure 7 As shown, the system mainly includes two modules: code cutting and third-party SDK identification and dynamic behavior detection and analysis. Among them, the code cutting and third-party SDK identification module mainly analyzes the code of the APK file of the APP by reverse analysis of the APP, using code block cutting to identify which third-party SDKs are contained in it and which code blocks these SDKs contain; the dynamic behavior detection and analysis module is used to perform honeypot simulation execution on the APP containing a specific third-party SDK, capture the sensitive behavior information generated by it, analyze the call stack information generated by these sensitive behaviors, and determine whether the initiator of these sensitive behaviors belongs to the third-party SDK that needs to be detected through code matching.

[0110] The system in the above embodiment uses code cutting to cut the code of the APK file of the APP application into independent code blocks, and then uses manual marking or cluster analysis to identify the third-party SDK therein; for the APP containing a specific third-party SDK, a dynamic honeypot is used to perform simulated operation to detect the sensitive behavior generated by it, and then the dynamic behavior belonging to the third-party SDK is determined by backtracing the call stack information, thereby achieving the purpose of dynamic behavior detection of the specific third-party SDK.

[0111] Based on the same inventive concept, a third-party SDK behavior detection device is also provided in the embodiment of the present application, and the third-party SDK behavior detection device can be deployed in the server. Since the device is a device corresponding to the third-party SDK behavior detection method provided in the embodiment of the present application, and the principle of solving the problem by the device is similar to that of the method, the implementation of the device can refer to the implementation of the above method, and the repeated parts will not be repeated.

[0112] Figure 8 FIG. 4 shows a structural block diagram of a third-party SDK behavior detection device provided in an embodiment of the present application. Figure 8 As shown, the third-party SDK behavior detection device includes: a simulation operation unit 801 and a behavior detection unit 802; wherein,

[0113] The simulation operation unit 801 is used to obtain the application to be detected including the target third-party SDK, and run the application to be detected in the simulator behavior honeypot;

[0114] The behavior detection unit 802 is used to obtain the call stack information when the target behavior occurs from the running log of the application to be detected according to the behavior characteristics of the set target behavior; determine the code block that is called when the target behavior is generated based on the obtained call stack information; if the called code block belongs to the code block of the target third-party SDK, determine that the target behavior is generated by the target third-party SDK.

[0115] In an optional embodiment, the simulation operation unit 801 is specifically configured to:

[0116] Perform code segmentation on the package file of the candidate application to obtain the code blocks contained in the candidate application; set SDK annotation information for each code block according to the ownership relationship between each code block and the third-party SDK, and the SDK annotation information is used to identify the third-party SDK to which the code block belongs; when the annotation information of each code block in the candidate application contains the target SDK annotation information, the candidate application is determined as the application to be detected.

[0117] In an optional embodiment, the behavior detection unit 802 is specifically configured to:

[0118] When the SDK annotation information of the called code block is consistent with the SDK annotation information of the code block of the target third-party SDK, it is determined that the called code block belongs to the code block of the target third-party SDK.

[0119] In an optional embodiment, the simulation operation unit 801 is specifically configured to:

[0120] For each candidate application, decompile the program package file of the candidate application to obtain a code package of the candidate application;

[0121] Code segmentation is performed on the code package of the candidate application to obtain code blocks contained in the candidate application.

[0122] In an optional embodiment, the behavior detection unit 802 is specifically configured to:

[0123] Get the call chain from the call stack information; the call chain includes function information of multiple call points;

[0124] Remove the function information of the call point associated with the system function from the call chain;

[0125] According to the function information of the remaining call points in the call chain, the code block called when the target behavior is generated is determined.

[0126] Based on the same inventive concept, an electronic device is also provided in an embodiment of the present application. In one embodiment, the electronic device may be a server. In this embodiment, the structure of the electronic device may be as follows: Fig. 9 As shown, it includes a memory 901 , a communication module 903 and one or more processors 902 .

[0127] The memory 901 is used to store computer programs executed by the processor 902. The memory 901 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system and programs required for running the instant messaging function, etc.; the data storage area may store various instant messaging information and operation instruction sets, etc.

[0128] The memory 901 may be a volatile memory, such as a random-access memory (RAM); the memory 901 may also be a non-volatile memory, such as a read-only memory, a flash memory, a hard disk drive (HDD) or a solid-state drive (SSD), or the memory 901 may be any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 901 may be a combination of the above memories.

[0129] The processor 902 may include one or more central processing units (CPU) or a digital processing unit, etc. The processor 902 is configured to implement the above-mentioned third-party SDK behavior detection method when calling the computer program stored in the memory 901 .

[0130] The communication module 903 is used to communicate with terminal devices or other servers.

[0131] The specific connection medium between the memory 901, the communication module 903 and the processor 902 is not limited in the embodiment of the present application. Fig. 9 In the embodiment, the memory 901 and the processor 902 are connected via a bus 904. The bus 904 is connected to the processor 902 via a bus 904. Fig. 9 The connections between other components are shown in bold lines, and are not intended to be limiting. Bus 904 can be divided into address bus, data bus, control bus, etc. For ease of representation, Fig. 9 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0132] The memory 901 stores a computer storage medium, which stores computer executable instructions, which are used to implement the third-party SDK behavior detection method of the embodiment of the present application. The processor 902 is used to execute the third-party SDK behavior detection method.

[0133] An embodiment of the present application further provides a computer storage medium, in which computer executable instructions are stored, and the computer executable instructions are used to implement the method for detecting third-party SDK behavior recorded in any embodiment of the present application.

[0134] In some possible implementations, various aspects of the third-party SDK behavior detection method provided in the present application may also be implemented in the form of a program product, which includes program code. When the program product is run on a computer device, the program code is used to enable the computer device to execute the steps of the third-party SDK behavior detection method according to various exemplary embodiments of the present application described above in this specification. For example, the computer device may execute the following steps: Figure 2 The process of the method for detecting third-party SDK behavior of steps S201 to S205 is shown.

[0135] A person skilled in the art can understand that: all or part of the steps of implementing the above method embodiment can be completed by hardware related to program instructions, and the aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps of the above method embodiment; and the aforementioned storage medium includes: mobile storage devices, read-only memories (ROM, Read-Only Memory), random access memories (RAM, Random Access Memory), disks or optical disks, etc. Various media that can store program codes.

[0136] The above description is only a specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application.

Claims

1. A method for detecting third-party SDK behavior, characterized in that: include: Based on the pre-marked attribution relationship between the third-party software development toolkit SDK and the code block, a code block data sample set of the attribution relationship between the third-party SDK and the code block is established; Based on the code block data sample set, code segmentation is performed on the program package file of the candidate application to obtain each new code block; For each new code block, generating a key value corresponding to the new code block according to basic information of the new code block; Performing cluster analysis on each of the new code blocks according to each key value, respectively obtaining the attribution relationship between each of the new code blocks and the third-party SDK, and adding the attribution relationship obtained according to the cluster analysis to the code block data sample set; Based on the attribution relationship between the code block and the third-party SDK in the code block data sample set, obtaining the application to be detected that includes the target third-party SDK, and running the application to be detected in the simulator behavior honeypot; According to the behavior characteristics of the set target behavior, the call stack information when the target behavior occurs is obtained from the running log of the application to be detected; the behavior characteristics include one or more of network access, sub-package loading, command execution, and elf file access; Obtain a call chain from the call stack information; each call chain corresponds to a target behavior; the call chain includes function information of multiple call points; Removing function information of a call point associated with a system function from the call chain; Determine, according to the function information of the remaining call points in the call chain, a code block that is called when the target behavior is generated; If the called code block belongs to the code block of the target third-party SDK, it is determined that the target behavior is generated by the target third-party SDK.

2. The method according to claim 1, characterized in that The step of obtaining the application to be detected that includes the target third-party software development kit SDK includes: Perform code segmentation on the package file of the candidate application to obtain various code blocks contained in the candidate application; According to the ownership relationship between each code block and the third-party SDK, SDK annotation information is set for each code block, where the SDK annotation information is used to identify the third-party SDK to which the code block belongs; When the annotation information of each code block in the candidate application includes the target SDK annotation information, the candidate application is determined as the application to be detected.

3. The method according to claim 2, characterized in that The called code block belongs to the code block of the target third-party SDK, specifically including: When the SDK annotation information of the called code block is consistent with the SDK annotation information of the code block of the target third-party SDK, it is determined that the called code block belongs to the code block of the target third-party SDK.

4. The method according to claim 2, characterized in that: The code segmentation of the program package file of the candidate application program to obtain the code blocks contained in the candidate application program includes: For each candidate application, decompile the program package file of the candidate application to obtain a code package of the candidate application; Code segmentation is performed on the code package of the candidate application to obtain code blocks included in the candidate application.

5. A third-party SDK behavior detection device, characterized in that: include: A simulation operation unit, used for establishing a code block data sample set of an attribution relationship between a third-party software development toolkit SDK and a code block based on a pre-marked attribution relationship between the third-party SDK and the code block; Based on the code block data sample set, code segmentation is performed on the package file of the candidate application to obtain each new code block; for each new code block, a key value corresponding to the new code block is generated according to basic information of the new code block; cluster analysis is performed on the new code blocks according to each key value to obtain the attribution relationship between the new code blocks and the third-party SDK, and the attribution relationship obtained according to the cluster analysis is added to the code block data sample set; based on the attribution relationship between the code block and the third-party SDK in the code block data sample set, the application to be detected containing the target third-party SDK is obtained, and the application to be detected is run in the simulator behavior honeypot; A behavior detection unit is used to obtain call stack information when the target behavior occurs from the running log of the application to be detected according to the behavior characteristics of the set target behavior; the behavior characteristics include one or more of network access, sub-package loading, command execution, and elf file access; from the call stack information, a call chain is obtained; each call chain corresponds to a target behavior once; the call chain includes function information of multiple call points; from the call chain, the function information of the call points associated with the system function is removed; based on the function information of the remaining call points in the call chain, the code block called when the target behavior is generated is determined; if the called code block belongs to the code block of the target third-party SDK, it is determined that the target behavior is generated by the target third-party SDK.

6. The device according to claim 5, characterized in that The simulation operation unit is specifically used for: Perform code segmentation on the package file of the candidate application to obtain various code blocks contained in the candidate application; According to the ownership relationship between each code block and the third-party SDK, SDK annotation information is set for each code block, where the SDK annotation information is used to identify the third-party SDK to which the code block belongs; When the annotation information of each code block in the candidate application includes the target SDK annotation information, the candidate application is determined as the application to be detected.

7. The device according to claim 5, characterized in that The behavior detection unit is specifically used for: When the SDK annotation information of the called code block is consistent with the SDK annotation information of the code block of the target third-party SDK, it is determined that the called code block belongs to the code block of the target third-party SDK.

8. A computer-readable storage medium, wherein a computer program is stored in the computer-readable storage medium, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 4 is implemented.

9. An electronic device, characterized in that: The method comprises a memory and a processor, wherein the memory stores a computer program executable on the processor, and when the computer program is executed by the processor, the method according to any one of claims 1 to 4 is implemented.

Citation Information

Patent Citations

  • Attack information processing method and device as well as Internet of Things honeypot system

    CN108769071A

  • Malicious code detection method and device, electronic equipment and storage medium

    CN110737887A

  • Method and system for discovering that Android application introduces third-party tool, and storage medium

    CN111124486A

  • Data leakage main body determination method and apparatus, equipment and readable storage medium

    CN111753330A