Risk detection method, device and equipment of SDK

Abstract

The application discloses a risk detection method, device and equipment of SDK, and the method comprises the steps of obtaining an application program containing a to-be-detected SDK; obtaining logs generated by the application program running in a preset first honeypot; when the logs indicate that the first honeypot is not a valid honeypot, determining a probability value of the first honeypot being identified; wherein the valid target honeypot is a honeypot successfully inducing the to-be-detected SDK to produce a risk behavior; when the probability value is greater than a preset probability threshold, generating a second honeypot according to the logs and a business type of the to-be-detected SDK, and determining a risk level of the SDK according to logs generated by the application program running in the second honeypot.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to a risk detection method, apparatus and device for an SDK. Background Technology

[0002] Currently, the use of SDKs (Software Development Kits) is very common, and a single product may integrate multiple SDKs. With the widespread use of SDKs, related security issues are receiving increasing attention.

[0003] Existing SDK security testing methods typically involve information security personnel scanning the SDK code separately before its release to determine if vulnerabilities exist. However, due to limitations in the technical skills of these personnel, SDK vulnerabilities may not be fully discovered, thus posing potential security risks to products integrating the SDK.

[0004] Therefore, a risk detection method for SDKs is needed to effectively detect SDK risks and avoid potential security risks to products that integrate the SDK. Summary of the Invention

[0005] This invention provides a method, apparatus, and device for detecting risks in an SDK, thereby addressing the problem that existing technologies cannot effectively detect SDK risks and avoiding potential security risks to products that integrate the SDK.

[0006] To solve the above-mentioned technical problems, the present invention is implemented as follows:

[0007] Firstly, a risk detection method for an SDK is provided, the method comprising:

[0008] Retrieve the application containing the SDK to be tested;

[0009] Obtain the logs generated by the application running in the preset first honeypot;

[0010] When the log indicates that the first honeypot is not a valid honeypot, the probability value of the first honeypot being identified is determined; wherein, the valid target honeypot is the honeypot that successfully induces the SDK to be detected to produce risky behavior;

[0011] When the probability value is greater than a preset probability threshold, a second honeypot is generated based on the logs and the service type of the SDK to be detected, and the risk level of the SDK is determined based on the logs generated by the application running in the second honeypot.

[0012] Secondly, a risk detection device for an SDK is provided, the device comprising:

[0013] The first acquisition module is used to acquire applications containing the SDK to be detected.

[0014] The second acquisition module is used to acquire the logs generated by the application running in the preset first honeypot;

[0015] The first determining module is used to determine the probability value of the first honeypot being identified when the log indicates that the first honeypot is not a valid honeypot; wherein, the valid target honeypot is a honeypot that successfully induces the SDK to be detected to produce risky behavior;

[0016] The second determining module is used to generate a second honeypot based on the logs and the service type of the SDK to be detected when the probability value is greater than a preset probability threshold, and to determine the risk level of the SDK based on the logs generated by the application running in the second honeypot.

[0017] Thirdly, a risk detection device for an SDK is provided, the risk detection device for the SDK including a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the method described in the first aspect.

[0018] Fourthly, a computer-readable storage medium is provided, characterized in that a computer program is stored on the computer-readable storage medium, and the computer program, when executed by a processor, implements the steps of the method described in the first aspect.

[0019] In this embodiment of the invention, when performing risk detection on an SDK, an application containing the SDK can be obtained, along with logs generated by the application running in a preset first honeypot. When the logs indicate that the first honeypot is not an effective honeypot, i.e., the first honeypot has not successfully induced the SDK under test to produce risky behavior, the probability value of the first honeypot being identified is determined. When the probability value is greater than a preset probability threshold, a second honeypot can be generated based on the logs and the business type of the SDK under test, and the risk level of the SDK can be determined based on the logs generated by the application running in the second honeypot.

[0020] Therefore, in this embodiment of the invention, when performing risk detection on the SDK, a preset first honeypot can be used for detection. If the first honeypot fails to detect any security risks in the SDK, it can be further determined whether the first honeypot has a high probability of being identified. If it has a high probability of being identified, a targeted second honeypot can be generated based on the logs generated by the application including the SDK running in the first honeypot and the business type of the SDK. The risk level of the SDK can then be determined based on the logs generated by the application including the SDK running in the second honeypot. Since the SDK can be securityly detected using a targeted second honeypot, instead of simply relying on the first honeypot, the accuracy of SDK detection can be effectively improved. Attached Figure Description

[0021] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings:

[0022] Figure 1 A flowchart illustrating a risk detection method for an SDK provided in one embodiment of the present invention;

[0023] Figure 2 A schematic diagram of the module composition of a risk detection device for an SDK provided in one embodiment of the present invention;

[0024] Figure 3 This is a schematic diagram of the hardware structure of a risk detection device for an SDK provided in one embodiment of the present invention. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0026] The technical solutions provided by the various embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0027] Please see Figure 1 , Figure 1 This is a flowchart illustrating a risk detection method for an SDK provided in one embodiment of the present invention, as shown below. Figure 1 As shown, the method includes the following steps:

[0028] Step 102: Obtain the application containing the SDK to be tested.

[0029] Step 104: Obtain the logs generated by the application running in the preset first honeypot;

[0030] Step 106: When the log indicates that the first honeypot is not a valid honeypot, determine the probability value of the first honeypot being identified; where a valid target honeypot is a honeypot that successfully induces the SDK to be detected to produce risky behavior.

[0031] Step 108: When the probability value is greater than the preset probability threshold, a second honeypot is generated based on the logs and the business type of the SDK to be detected, and the risk level of the SDK is determined based on the logs generated by the application running in the second honeypot.

[0032] In this embodiment of the invention, for the SDK to be detected, the application integrating the SDK can be obtained first, that is, the application containing the SDK can be obtained. Then, the business type of the SDK can be further obtained, so as to generate a first honeypot based on the business type.

[0033] The business type of the SDK to be tested can be determined based on the functions it provides, and can be determined from the relevant documentation or examples in the SDK to be tested. For example, the business type of the SDK to be tested can include: third-party login and sharing, payment, push notification, advertising, data statistics and analysis, map, etc.

[0034] In this embodiment of the invention, the higher the importance of the business type of the SDK to be detected, the higher the level of the preset first honeypot. For example, when the business type of the SDK to be detected is payment, its importance is high, and the preset first honeypot can be a high-interaction honeypot; when the business type of the SDK to be detected is advertising, its importance is low, and the preset first honeypot can be a low-interaction honeypot.

[0035] In this embodiment of the invention, after the first honeypot is generated, logs generated by the application running in the preset first honeypot can be obtained, and the validity of the first honeypot can be determined based on the logs.

[0036] In this embodiment of the invention, considering that honeypots may be identified, and that if a honeypot is identified, the risky behavior in the SDK may not be attacked on the honeypot temporarily, but will be attacked on the real system after the real system is replaced, causing security risks to the real system, this embodiment of the invention can determine whether the first honeypot is a honeypot that successfully induces the SDK to be detected to produce risky behavior based on the logs generated during the operation of the application after it runs in the preset first honeypot, and further determine the probability value of the first honeypot being identified if it is not a valid honeypot.

[0037] In determining the probability of the first honeypot being identified, the associated simulation configuration data corresponding to the first honeypot can be determined first based on the business type of the SDK to be detected. Then, based on the logs, the operation events of the application running in the first honeypot and targeting the associated simulation configuration data corresponding to the first honeypot can be obtained. The operation events include the operation type and operation time. After determining the operation events, the probability of the first honeypot being identified can be determined based on the degree of dispersion of the operation events in time.

[0038] In this embodiment of the invention, the association between the business type of each SDK and the corresponding simulated configuration data can be preset. For example, the association between data statistical analysis classes and accessible interfaces and addresses can be preset. Based on the business type of each SDK, simulated configuration data with a high probability of risky behavior can be determined. This data is also more likely to lead to the identification of the first honeypot. Therefore, after obtaining the business type of the SDK to be detected, the associated simulated configuration data corresponding to the first honeypot can be determined based on the business type of the SDK to be detected.

[0039] After determining the associated simulation configuration data corresponding to the first honeypot, the operation events of the application targeting the associated simulation configuration data of the first honeypot can be obtained from the logs generated by the application containing the SDK to be tested running in the first honeypot. These operation events can include the operation type and the operation time. For example, the operation type could be: read data; the operation time could be: January 1, 2022, 20:00.

[0040] In this embodiment of the invention, the application can determine what operations it performed on the associated simulation configuration data at what time based on the logs and the associated simulation configuration data corresponding to the first honeypot, so as to evaluate whether the first honeypot was identified through these associated configuration data.

[0041] After obtaining the operation events of the associated simulated configuration data corresponding to the first honeypot, the probability value of the first honeypot being identified can be determined based on the degree of dispersion of the operation events in time.

[0042] In this embodiment of the invention, considering that when it is suspected that the first honeypot is not a real system through a certain associated simulation configuration data, there is a high probability that other associated simulation configuration data will be obtained for verification, and when it is confirmed through multiple verifications that the first honeypot is not a real system, the associated simulation configuration data will no longer be verified, therefore, this embodiment of the invention determines the probability value of the first honeypot being identified based on the degree of dispersion of the operation event in time.

[0043] In determining the probability of the first honeypot being identified, the operation time corresponding to each operation event can be obtained, along with the number of first operation events whose time interval between corresponding operation times is less than a first preset time interval, and the maximum number of second operation events corresponding to operation times within a second preset time interval. Then, the probability of the first honeypot being identified can be determined based on the number of first operation events, the number of second operation events, the total number of operation events, and a preset probability calculation formula. The second preset time interval can be less than the first preset time interval.

[0044] In one example, the operation events may include five operation events: operation event 1, operation event 2, operation event 3, operation event 4, and operation event 5. The operation times corresponding to these five operation events may be, in order: 20:00 on January 1, 2022, 20:05 on January 1, 2022, 20:08 on January 1, 2022, 20:09 on January 1, 2022, and 20:11 on January 1, 2022. The first operation time interval can be 3 minutes and 30 seconds, and the second operation time interval can be 2 minutes and 10 seconds. Given that the interval between operation events 1 and 2 is 5 minutes, between operation events 2 and 3 is 3 minutes, between operation events 3 and 4 is 1 minute, and between operation events 4 and 5 is 2 minutes, the first operation event can include operation events 2, 3, 4, and 5. Therefore, the number of first operation events is 4. Given that the interval between operation events 3 and 4 is 1 minute, and the time intervals between other operation events (including the time intervals between operation events 3 or 4 and other operation events, and the time intervals between other operation times) are greater than 2 minutes and 10 seconds, the second operation event can include operation events 3 and 4. Therefore, the number of second operation events is 2.

[0045] After determining the number of first operation events, the number of second operation events, and the total number of operation events, the probability value of the first honeypot being identified can be determined according to the preset probability calculation formula.

[0046] In one example, the preset probability calculation formula can be:

[0047]

[0048] Where P can be the probability value of the first honeypot being identified; S 总 S1 can be the total number of operation events; S2 can be the number of the first operation events; S2 can be the number of the second operation events.

[0049] When the number of first operation events is 4, the number of second operation events is 2, and the total number of operation events is 5, the probability value of the first honeypot being identified can be: 0.8e 0.5 .

[0050] After determining the probability of the first honeypot being identified, it can be determined whether this probability value is greater than a preset probability threshold. If it is not greater, the risk level of the SDK to be detected can be determined directly based on the logs generated by the application running in the preset first honeypot. Since these logs indicate that the application including the SDK to be detected has not exhibited any risky behavior, the risk level of the SDK to be detected can be determined to be low.

[0051] If the probability value is greater than the preset probability threshold, it means that the first honeypot has a high probability of being identified. At this time, a second honeypot can be generated based on the logs and the business type of the SDK to be detected, and the risk level of the SDK can be determined based on the logs generated by the application running in the second honeypot.

[0052] In the process of generating a second honeypot based on logs and the business type of the SDK to be detected, the target association simulation configuration data corresponding to operation events with low temporal dispersion can be obtained first. Then, the real association configuration data corresponding to the target association simulation configuration data in the real system simulated by the first honeypot can be determined. The target association simulation configuration data is then adjusted based on the real association configuration data, wherein the similarity between the adjusted target association simulation configuration data and the real association configuration is not higher than a similarity threshold. Finally, the first honeypot is adjusted based on the adjusted target association simulation configuration data to generate the second honeypot.

[0053] In this invention, when generating a second honeypot based on logs and the service type of the SDK to be detected, target-related simulation configuration data corresponding to operation events with low temporal dispersion can be obtained; that is, the associated simulation configuration data of the centralized operations can be obtained. Since this associated simulation configuration data has a high probability of leading to the identification of the first honeypot, this embodiment of the invention can focus on adjusting this associated simulation configuration data to generate the corresponding second honeypot.

[0054] When adjusting the target association simulation configuration data, the real association configuration data corresponding to the target association simulation configuration data in the real system of the first honeypot simulation can be determined first. Then, the target association simulation configuration data can be adjusted according to the real association configuration data.

[0055] In one example, when adjusting the target association simulation configuration data based on the real association configuration data, a weighting coefficient can be determined based on the temporal dispersion of operation events with low temporal dispersion, and the target association simulation configuration data can be adjusted based on the weighting coefficient and the real association configuration data.

[0056] When determining the weighting coefficients based on the temporal dispersion of operation events with low temporal dispersion, the number of third operation events with low temporal dispersion whose time intervals are less than a third preset time interval, and the number of fourth operation events with the highest number of low temporal dispersion operation events corresponding to operation times within a fourth preset time interval, can be obtained. Then, the weighting coefficients can be determined based on the number of third operation events, the number of fourth operation events, the total number of operation events with low temporal dispersion, and a preset weighting formula. The fourth preset time interval can be less than the third preset time interval.

[0057] In one example, operation events with low temporal dispersion can include operation events 2, 3, 4, and 5. The corresponding operation times for these four events can be January 1, 2022, 20:05, January 1, 2022, 20:08, January 1, 2022, 20:09, and January 1, 2022, 20:11, respectively. The third operation time interval can be 2 minutes and 30 seconds, and the second operation time interval can be 1 minute and 30 seconds. Therefore, the interval between operation events 2 and 3 is 3 minutes, between operation events 3 and 4 is 1 minute, and between operation events 4 and 5 is 2 minutes. Thus, the third operation event can include operation events 3, 4, and 5, and the number of first operation events is 3. Since the interval between operation events 3 and 4 is 1 minute, and the time intervals between other operation events are greater than 1 minute and 30 seconds, the fourth operation event can include operation events 3 and 4. Therefore, the number of fourth operation events is 2.

[0058] After determining the number of third operation events, the number of fourth operation events, and the total number of operation events with low temporal dispersion, the weighting coefficients can be calculated according to the preset weighting formula.

[0059] In one example, the preset weight calculation formula can be:

[0060]

[0061] Where K can be a weighting coefficient; S0 can be the total number of operation events with low time dispersion; S3 can be the number of third operation events; and S4 can be the number of fourth operation events.

[0062] When the number of first operation events is 3, the number of second operation events is 2, and the total number of operation events is 4, the weighting coefficient can be 0.75e. 0.22 .

[0063] After adjusting the target association simulation configuration data based on the weighting coefficients and the actual association configuration data, a second honeypot can be generated, and the risk level of the SDK can be determined based on the logs generated by the application running in the second honeypot.

[0064] In this embodiment of the invention, when performing risk detection on an SDK, an application containing the SDK can be obtained, along with logs generated by the application running in a preset first honeypot. When the logs indicate that the first honeypot is not an effective honeypot, i.e., the first honeypot has not successfully induced the SDK under test to produce risky behavior, the probability value of the first honeypot being identified is determined. When the probability value is greater than a preset probability threshold, a second honeypot can be generated based on the logs and the business type of the SDK under test, and the risk level of the SDK can be determined based on the logs generated by the application running in the second honeypot.

[0065] Therefore, in this embodiment of the invention, when performing risk detection on the SDK, a preset first honeypot can be used for detection. If the first honeypot fails to detect any security risks in the SDK, it can be further determined whether the first honeypot has a high probability of being identified. If it has a high probability of being identified, a targeted second honeypot can be generated based on the logs generated by the application including the SDK running in the first honeypot and the business type of the SDK. The risk level of the SDK can then be determined based on the logs generated by the application including the SDK running in the second honeypot. Since the SDK can be securityly detected using a targeted second honeypot, instead of simply relying on the first honeypot, the accuracy of SDK detection can be effectively improved.

[0066] Corresponding to the above-mentioned SDK risk detection method, this embodiment of the invention also provides an SDK risk detection device. Figure 2 This is a schematic diagram of the module composition of the risk detection device for the SDK provided in this embodiment of the invention, as shown below. Figure 2 As shown, the risk detection device of this SDK includes:

[0067] The first acquisition module 21 is used to acquire an application containing the SDK to be detected;

[0068] The second acquisition module 22 is used to acquire the logs generated by the application running in the preset first honeypot;

[0069] The first determining module 23 is used to determine the probability value of the first honeypot being identified when the log indicates that the first honeypot is not a valid honeypot; wherein, the valid target honeypot is a honeypot that successfully induces the SDK to be detected to produce risky behavior;

[0070] The second determining module 24 is used to generate a second honeypot based on the logs and the service type of the SDK to be detected when the probability value is greater than a preset probability threshold, and to determine the risk level of the SDK based on the logs generated by the application running in the second honeypot.

[0071] Optionally, the device further includes:

[0072] The third acquisition module 25 is used to acquire the service type of the SDK to be detected before acquiring the logs generated by the application running in the preset first honeypot;

[0073] The generation module 26 is used to generate a first honeypot based on the service type of the SDK to be detected.

[0074] The generation module 26 is used for:

[0075] Determining the probability value of the first honeypot being identified includes:

[0076] Based on the service type of the SDK to be detected, determine the associated simulation configuration data corresponding to the first honeypot;

[0077] Based on the logs, obtain the operation events of the application on the associated simulated configuration data corresponding to the first honeypot when the application is running in the first honeypot; the operation events include the operation type and the operation time.

[0078] The probability value of the first honeypot being identified is determined based on the degree of dispersion of the operation events over time.

[0079] Optionally, the generation module 26 is further configured to:

[0080] Obtain the operation time corresponding to each of the operation events;

[0081] Determine the number of first operation events whose time interval between corresponding operation times is less than a first preset time interval, and the maximum number of second operation events corresponding to operation times within a second preset time interval;

[0082] The probability value of the first honeypot being identified is determined based on the number of the first operation events, the number of the second operation events, the total number of operation events, and a preset probability calculation formula.

[0083] Optionally, the preset probability calculation formula is:

[0084]

[0085] Where P is the probability value of the first honeypot being identified; S 总 S1 is the total number of operation events; S2 is the number of the first operation events; S3 is the number of the second operation events.

[0086] Optionally, the generation module 26 is used to:

[0087] Obtain target-related simulation configuration data corresponding to operation events with low temporal dispersion;

[0088] Determine the real associated configuration data in the real system of the first honeypot simulation that corresponds to the target associated simulation configuration data;

[0089] The target association simulation configuration data is adjusted based on the actual association configuration data; wherein the similarity between the adjusted target association simulation configuration data and the actual association configuration is not higher than a similarity threshold.

[0090] Based on the adjusted target-related simulation configuration data, the first honeypot is adjusted to generate the second honeypot.

[0091] Optionally, the generation module 26 is further configured to:

[0092] The weighting coefficients are determined based on the degree of temporal dispersion of the operational events with low temporal dispersion.

[0093] The target association simulation configuration data is adjusted based on the weighting coefficients and the actual association configuration data.

[0094] In this embodiment of the invention, when performing risk detection on an SDK, an application containing the SDK can be obtained, along with logs generated by the application running in a preset first honeypot. When the logs indicate that the first honeypot is not an effective honeypot, i.e., the first honeypot has not successfully induced the SDK under test to produce risky behavior, the probability value of the first honeypot being identified is determined. When the probability value is greater than a preset probability threshold, a second honeypot can be generated based on the logs and the business type of the SDK under test, and the risk level of the SDK can be determined based on the logs generated by the application running in the second honeypot.

[0095] Therefore, in this embodiment of the invention, when performing risk detection on the SDK, a preset first honeypot can be used for detection. If the first honeypot fails to detect any security risks in the SDK, it can be further determined whether the first honeypot has a high probability of being identified. If it has a high probability of being identified, a targeted second honeypot can be generated based on the logs generated by the application including the SDK running in the first honeypot and the business type of the SDK. The risk level of the SDK can then be determined based on the logs generated by the application including the SDK running in the second honeypot. Since the SDK can be securityly detected using a targeted second honeypot, instead of simply relying on the first honeypot, the accuracy of SDK detection can be effectively improved.

[0096] Corresponding to the above-mentioned SDK risk detection method, this embodiment of the invention also provides an SDK risk detection device. Figure 3 This is a schematic diagram of the hardware structure of a risk detection device for an SDK provided in one embodiment of the present invention.

[0097] The risk detection device for this SDK can be a terminal device or server, etc., provided in the above embodiments for detecting the risks of the SDK.

[0098] The risk detection device for the SDK can vary significantly depending on its configuration and performance. It may include one or more processors 301 and memory 302, with memory 302 storing one or more applications or data. Memory 302 can be temporary or persistent storage. Applications stored in memory 302 may include one or more modules (not shown), each module including a series of computer-executable instructions for the SDK's risk detection device. Furthermore, processor 301 may be configured to communicate with memory 302, executing the series of computer-executable instructions in memory 302 on the SDK's risk detection device. The SDK's risk detection device may also include one or more power supplies 303, one or more wired or wireless network interfaces 304, one or more input / output interfaces 305, and one or more keyboards 306.

[0099] Specifically, in this embodiment, the risk detection device of the SDK includes a memory and one or more programs. One or more programs are stored in the memory, and one or more programs may include one or more modules. Each module may include a series of computer-executable instructions in a device that determines the server identifier corresponding to the application installation package, and is configured to be executed by one or more processors. The one or more programs contain instructions for performing the above steps and can achieve the same technical effect as the above steps. This embodiment will not be elaborated further.

[0100] Furthermore, based on the above Figure 1 The method shown in this specification, in one or more embodiments, also provides a storage medium for storing computer-executable instruction information. In one specific embodiment, the storage medium can be a USB flash drive, optical disc, hard disk, etc. When the computer-executable instruction information stored in the storage medium is executed by the processor, it can realize the various processes implemented by the risk detection method device in the above-described SDK risk detection method embodiment. To avoid repetition, it will not be described again here.

[0101] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using a hardware physical module. For example, a Programmable Logic Device (PLD) (e.g., a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program a digital system themselves to "integrate" it onto a PLD, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0102] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0103] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0104] For ease of description, the above apparatus is described by dividing it into various functional units. Of course, in implementing this invention, the functions of each unit can be implemented in one or more software and / or hardware components.

[0105] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0106] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0107] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0108] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0109] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0110] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0111] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0112] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0113] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0114] This invention can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This invention can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0115] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0116] The above description is merely an embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the present invention should be included within the scope of the claims of the present invention.

Claims

1. A risk detection method for an SDK, characterized in that, The method includes: Retrieve the application containing the SDK to be tested; Obtain the logs generated by the application running in the preset first honeypot; When the log indicates that the first honeypot is not a valid honeypot, the probability value of the first honeypot being identified is determined; wherein, the valid honeypot is the honeypot that successfully induces the SDK to be detected to produce risky behavior; When the probability value is greater than a preset probability threshold, a second honeypot is generated based on the logs and the service type of the SDK to be detected, and the risk level of the SDK is determined based on the logs generated by the application running in the second honeypot. Before obtaining the logs generated by the application running in the preset first honeypot, the method further includes: Obtain the service type of the SDK to be tested; Based on the service type of the SDK to be detected, generate the first honeypot; Determining the probability value of the first honeypot being identified includes: Based on the service type of the SDK to be detected, determine the associated simulation configuration data corresponding to the first honeypot; Based on the logs, obtain the operation events of the application on the associated simulated configuration data corresponding to the first honeypot when the application is running in the first honeypot; the operation events include the operation type and the operation time. The probability value of the first honeypot being identified is determined based on the degree of dispersion of the operation events over time. The step of generating a second honeypot based on the logs and the service type of the SDK to be detected includes: Obtain target-related simulation configuration data corresponding to operation events with low temporal dispersion; Determine the real associated configuration data in the real system of the first honeypot simulation that corresponds to the target associated simulation configuration data; The target association simulation configuration data is adjusted based on the actual association configuration data; wherein the similarity between the adjusted target association simulation configuration data and the actual association configuration is not higher than a similarity threshold. Based on the adjusted target-related simulation configuration data, the first honeypot is adjusted to generate the second honeypot.

2. The method according to claim 1, characterized in that, Determining the probability value of the first honeypot being identified based on the temporal dispersion of the operation event includes: Obtain the operation time corresponding to each of the operation events; Determine the number of first operation events whose time interval between corresponding operation times is less than a first preset time interval, and the maximum number of second operation events corresponding to operation times within a second preset time interval; The probability value of the first honeypot being identified is determined based on the number of the first operation events, the number of the second operation events, the total number of operation events, and a preset probability calculation formula.

3. The method according to claim 2, characterized in that, The preset probability calculation formula is as follows: in, This represents the probability value of the first honeypot being identified. This represents the total number of operation events. The number of the first operation events; This represents the number of events in the second operation.

4. The method according to claim 1, characterized in that, The step of adjusting the target association simulation configuration data based on the actual association configuration data includes: The weighting coefficients are determined based on the degree of temporal dispersion of the operational events with low temporal dispersion. The target association simulation configuration data is adjusted based on the weighting coefficients and the actual association configuration data.

5. A risk detection device for an SDK, used to execute the method of claim 1, characterized in that, The device includes: The first acquisition module is used to acquire applications containing the SDK to be detected. The second acquisition module is used to acquire the logs generated by the application running in the preset first honeypot; The first determining module is used to determine the probability value of the first honeypot being identified when the log indicates that the first honeypot is not a valid honeypot; wherein, the valid honeypot is a honeypot that successfully induces the SDK to be detected to produce risky behavior; The second determining module is used to generate a second honeypot based on the logs and the service type of the SDK to be detected when the probability value is greater than a preset probability threshold, and to determine the risk level of the SDK based on the logs generated by the application running in the second honeypot.

6. A risk detection device for an SDK, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the method as described in any one of claims 1 to 4.

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

Images