CN111654495B

CN111654495B - Method, apparatus, device and storage medium for determining traffic generation source

Info

Publication number: CN111654495B
Application number: CN202010492846.7A
Authority: CN
Inventors: 崔乃天; 贾志军
Original assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Current assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Priority date: 2020-06-03
Filing date: 2020-06-03
Publication date: 2023-06-27
Anticipated expiration: 2040-06-03
Also published as: CN111654495A

Abstract

The embodiment of the application discloses a method, a device, electronic equipment and a computer readable storage medium for determining a traffic generation source, and relates to the field of privacy data security. One embodiment of the method comprises the following steps: acquiring the actual flow of an application program to be tested; extracting an actual characteristic character string from the actual flow; and determining a source SDK for generating the actual flow according to the actual characteristic character strings, wherein the corresponding relation between each SDK and the characteristic character strings contained in the actual codes is recorded in advance. The embodiment provides a method for determining a source SDK based on code features of each SDK, compared with flow features used in the prior art, the code features are lower in change frequency, the corresponding relationship is easier to collect, update and maintain, and the source SDK for generating actual flow can be determined more accurately.

Description

Method, apparatus, device and storage medium for determining traffic generation source

Technical Field

The embodiment of the application relates to the technical field of traffic tracking, in particular to the technical field of privacy data security.

Background

With the development of electronic informatization technology, privacy problems of personal data of users are increasingly emphasized by society, and government departments are continuously put forth laws and regulations of personal information protection.

As stated, the operating body of an Application (APP) has security responsibility for the behavior of personal information collected/content transmitted/URL transmitted (Uniform Resource Locator ) by the SDK (Software Development Kit, software development kit) integrated within its APP. The APP developer is of course quite aware of the behavior of the own SDK it uses (also called the first party SDK), but little is known about the behavior of the third party SDK it uses. In order to ensure that the private data of the user is not privately used by the third party SDK, the source of the traffic generated by the APP during operation needs to be accurately identified, so that the judgment of whether the source is the third party SDK can be performed under the condition that the source is specific to the SDK, and finally whether the private data of the user is privately used by the third party SDK is determined.

The prior art generally provides a method of pre-recording flow characteristics of various SDKs, and determining corresponding source SDKs by way of matching actual flow characteristics contained in the actual flow with flow characteristics of which SDKs are recorded.

Disclosure of Invention

The embodiment of the application provides a method, a device, electronic equipment and a computer readable storage medium for determining a flow generation source.

In a first aspect, an embodiment of the present application proposes a method for determining a traffic generating source, including: acquiring the actual flow of an application program to be tested; extracting an actual characteristic character string from the actual flow; determining a source SDK for generating actual flow according to the actual characteristic character string; wherein, the corresponding relation between each SDK and the characteristic character string contained in the actual code is recorded in advance.

In a second aspect, an embodiment of the present application proposes an apparatus for determining a traffic generating source, including: an actual flow obtaining unit configured to obtain an actual flow of an application program to be tested; an actual feature string extraction unit configured to extract an actual feature string from the actual traffic; a source SDK determining unit configured to determine a source SDK generating an actual flow from the actual feature string; wherein, the corresponding relation between each SDK and the characteristic character string contained in the actual code is recorded in advance.

In a third aspect, an embodiment of the present application provides an electronic device, including: at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to implement a method for determining a source of traffic generation as described in any one of the implementations of the first aspect when executed.

In a fourth aspect, embodiments of the present application provide a non-transitory computer-readable storage medium storing computer instructions for enabling a computer to implement a method for determining a traffic generation source as described in any one of the implementations of the first aspect when executed.

In a fifth aspect, embodiments of the present application provide a computer program product comprising a computer program which, when executed by a processor, implements a method as described in any of the implementations of the first aspect.

The embodiment of the application provides a method, a device, electronic equipment and a computer readable storage medium for determining a flow generation source, wherein the method comprises the steps of firstly obtaining actual flow of an application program to be tested; then, extracting an actual characteristic character string from the actual flow; finally, the source SDK generating the actual flow is determined according to the actual characteristic character string with the help of the corresponding relation between each pre-recorded SDK and the characteristic character string contained in the actual code.

Different from the method for determining the source SDK based on the flow characteristics of each SDK provided by the prior art, the embodiment of the application selects the characteristic character string which can more accurately relate the SDK with the generated flow, wherein the characteristic character string is the character string of the flow generated in the actual code and the actual code execution process of the SDK, that is, the embodiment of the application provides the method for determining the source SDK based on the code characteristics of each SDK, and compared with the method with the lower change frequency of the flow characteristics, the corresponding relation is easier to collect, update and maintain, and the source SDK for generating the actual flow can be more accurately determined.

It should be understood that the description in this section is not intended to identify key or critical features of the embodiments of the disclosure, nor is it intended to be used to limit the scope of the disclosure. Other features of the present disclosure will become apparent from the following specification.

Drawings

Other features, objects and advantages of the present application will become more apparent upon reading of the detailed description of non-limiting embodiments, made with reference to the following drawings, in which:

FIG. 1 is an exemplary system architecture in which the present application may be applied;

FIG. 2 is a flow chart of one embodiment of a method for determining a traffic generating source according to the present application;

FIG. 3 is a flow chart of another embodiment of a method for determining a flow generating source according to the present application;

FIG. 4 is a flow chart of one application scenario of a method for determining traffic generation sources according to the present application;

FIG. 5 is a schematic structural view of one embodiment of an apparatus for determining a flow generating source according to the present application;

fig. 6 is a block diagram of an electronic device suitable for implementing a method for determining a traffic generation source according to an embodiment of the present application.

Detailed Description

The present application is described in further detail below with reference to the drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the invention and are not limiting of the invention. It should be noted that, for convenience of description, only the portions related to the present invention are shown in the drawings.

It should be noted that, in the case of no conflict, the embodiments and features in the embodiments may be combined with each other. The present application will be described in detail below with reference to the accompanying drawings in conjunction with embodiments.

FIG. 1 illustrates an exemplary system architecture 100 to which embodiments of the methods, apparatus, electronic devices, and computer-readable storage media for determining traffic generation sources of the present application may be applied.

As shown in fig. 1, a system architecture 100 may include

terminal devices

101, 102, 103, a network 104, and a server 105. The network 104 is used as a medium to provide communication links between the

terminal devices

101, 102, 103 and the server 105. The network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.

The user may interact with the server 105 via the network 104 using the

terminal devices

101, 102, 103 to receive or send messages or the like. Various applications for implementing information communication between the

terminal devices

101, 102, 103 and the server 105, such as a personal data storage application, an APP security risk detection application, an online friend making application, an instant messaging application, and the like, may be installed on the terminal devices.

The

terminal devices

101, 102, 103 and the server 105 may be hardware or software. When the

terminal devices

101, 102, 103 are hardware, they may be various electronic devices with display screens, including but not limited to smartphones, tablets, laptop and desktop computers, etc.; when the

terminal devices

101, 102, 103 are software, they may be installed in the above-listed electronic devices, which may be implemented as a plurality of software or software modules, or may be implemented as a single software or software module, which is not particularly limited herein. When the server 105 is hardware, it may be implemented as a distributed server cluster formed by a plurality of servers, or may be implemented as a single server; when the server is software, the server may be implemented as a plurality of software or software modules, or may be implemented as a single software or software module, which is not particularly limited herein.

The

terminal devices

101, 102, 103 and the server 105 can provide various services through various built-in applications, for example, an APP security risk detection application that can provide an APP real-time traffic source SDK analysis service, and when the APP security risk detection application is run, the following effects can be achieved: firstly, the server 105 acquires actual traffic generated when an application program to be tested installed on the

terminal devices

101, 102, 103 transmitted through a network is used by a user; then, the server 105 extracts an actual feature string from the actual traffic; finally, the server 105 determines the source SDK that generated the actual traffic from the actual feature string with the help of the correspondence between each of the pre-recorded SDKs and the feature string contained in its actual code. That is, the server 105 achieves the object of determining the source SDK that generated the actual traffic based on the code characteristics of the SDK through the above-described processing steps, and outputs the determined source SDK as a result.

It should be noted that the actual traffic generated by the application program to be tested when used by the user may be stored in advance in the server 105 in various ways, in addition to being acquired from the

terminal devices

101, 102, 103 through the network 104. Thus, when the server 105 detects that such data has been stored locally (e.g., a pending source SDK determination task is also left in the pending queue), the actual traffic may optionally be obtained directly from locally, in which case the exemplary system architecture 100 may not include the

terminal devices

101, 102, 103 and network 104.

The method for determining the source of the generated traffic is generally performed by the server 105 having the stronger computing power and the more computing resources, and accordingly, the device for determining the source of the generated traffic is generally also disposed in the server 105. However, it should be noted that, when the

terminal devices

101, 102, 103 also have the required computing capability and computing resources, the

terminal devices

101, 102, 103 may also complete each operation performed by the server 105 through the APP security risk detection application installed thereon, and further output the same result as the server 105. Especially in the case that there are multiple terminal devices with different computing capabilities at the same time, but the APP security risk detection application may also make the terminal device execute the above-mentioned computation when it is determined that the terminal device has a stronger computing capability and more computing resources remain, so as to properly reduce the computing pressure of the server 105, and accordingly, the device for determining the source of traffic generation may also be provided in the

terminal devices

101, 102, 103. In this case, the exemplary system architecture 100 may also not include the server 105 and the network 104.

It should be understood that the number of terminal devices, networks and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

With continued reference to FIG. 2, there is shown an implementation flow 200 of one embodiment of a method for determining a traffic generating source according to the present application, including the steps of:

step 201: acquiring the actual flow of an application program to be tested;

this step aims at acquiring the actual traffic of an application under test (hereinafter, referred to simply as APP under test) by an execution subject (e.g., server 105 shown in fig. 1) of a method for determining a traffic generation source.

The APP to be tested can be the APP which is issued to the APP download platform and can be downloaded by the user, or the APP which is submitted to the APP download platform and is being issued and checked, the actual flow of the APP to be tested refers to network data generated by the APP to be tested in the actual system environment, and the network data comprises data generated when various SDKs, functions, interfaces and the like in the APP to be tested are called and executed.

The actual flow of the APP to be tested may be directly obtained from a local storage device by the execution body, or may be obtained from a non-local storage device (for example,

terminal devices

101, 102, 103 shown in fig. 1). The local storage device may be a data storage module, such as a server hard disk, disposed in the execution body, where the actual flow of the APP to be measured may be quickly read locally; the non-local storage device may be any other electronic device configured to store data, such as some user terminals, where the executing body may obtain the required actual flow of the APP to be tested by sending an obtaining command to the electronic device, or directly receive the APP to be tested sent by the electronic device, and the executing body is acquired by the executing body when running the APP to be tested by itself.

Step 202: extracting an actual characteristic character string from the actual flow;

on the basis of step 201, this step aims at extracting, by the above-described execution subject, an actual feature string from the acquired actual flow. The actual characteristic character string is a representative character string in all character strings generated when the actual code of the SDK in the APP to be tested is called and executed, and different SDKs have different actual codes, so that different actual characteristic character strings are used for representing different SDKs.

It should be understood that the same code may generate different flows under different operating environments due to the existence of branches, that is, the flow characteristics represented by one SDK with perfect functions are greatly affected by the actual operating environment, and each update often causes a change in the flow characteristics, so in the manner of recording the flow characteristics of each SDK to match, it is often difficult to comprehensively and accurately collect the flow characteristics of the corresponding SDK, and the workload is also very large. Aiming at the technical defect, the method starts from the code layer of the SDK, and collects the code features which can be uniquely expressed in the traffic, namely the feature character strings, so as to realize the aim of tracing the source SDK for generating the actual traffic through the feature character strings which have corresponding relations with the traffic and the actual code of the SDK respectively.

Specifically, all character strings capable of uniquely representing the code characteristics of one SDK in the traffic can be selected as characteristic character strings, for example, HTTP (hypertext transfer protocol) addresses appearing in the actual codes of the SDKs, and due to their actual effects, when data transmission is performed on the objects corresponding to the HTTP addresses, it is necessary to ensure that the contents of the HTTP addresses are completely accurate, otherwise, data transmission cannot be performed correctly, so that the HTTP addresses are character strings that exist in the same form in both the actual codes and the actual traffic, and therefore can be selected as characteristic character strings; of course, other character strings having the same or similar properties as the HTTP address may be selected as the characteristic character string. Even to achieve this effect, each SDK can be used as a feature string by requiring that it adds some flags or marks that can uniquely characterize its identity when it is packaged, and making these flags or marks appear at specific locations of traffic generated when the SDK to which it belongs is called and executed.

Step 203: and determining the source SDK for generating the actual flow according to the actual characteristic character string.

Based on step 202, this step aims to determine, by the execution subject, with the aid of the pre-recorded correspondence between each SDK and the feature string included in the actual code thereof, the source SDK that generates the actual flow according to the actual feature string, that is, find the actual SDK corresponding to the actual feature string through the pre-recorded correspondence, so that the actual SDK can be determined as the source SDK that generates the actual flow on the premise that the actual flow includes the actual feature string.

Furthermore, in order to facilitate maintenance and update of the correspondence between each SDK and the feature strings included in the actual code, the correspondence may be stored in a suitable form in combination with each actual requirement in the actual application scenario, for example, in a key value pair, a database table, or the like, and, of course, a source SDK identifier or an identification model may be constructed based on these correspondence, which is not limited specifically herein.

Unlike the method for determining the source SDK based on the flow characteristics of each SDK provided in the prior art, the method for determining the source of the flow provided in the embodiment of the present application selects the characteristic string capable of more accurately associating the SDK with the flow generated by the SDK, where the characteristic string is the string of the flow generated in the execution process of the actual code and the actual code of the SDK, that is, the embodiment of the present application provides a method for determining the source SDK based on the code characteristics of each SDK, where the code characteristics have a lower frequency of change and the correspondence is easier to collect and update and maintain than the flow characteristics, and the source SDK capable of more accurately determining the source SDK generating the actual flow.

In order to deepen understanding the implementation process of the present application, another flow 300 for determining a flow generation source is provided through fig. 3, and on the basis of the above embodiment, not only is a specific method for recording a correspondence relationship and constructing it into an SDK knowledge base that is convenient to use, but also after determining the source SDK, a determination result is finally output as to whether the APP to be tested meets the security privacy requirement according to whether the source SDK provides different subsequent processing schemes for a third party SDK. The method comprises the following steps:

Step 301: determining an HTTP address set contained in each SDK according to the actual code of each SDK;

this step aims at determining, by the above-described execution body, a set of HTTP addresses contained therein according to the actual code of each SDK, the set of HTTP addresses being a set of all different HTTP addresses contained in the actual code of the SDK.

An implementation, including but not limited to, may be the following steps:

identifying a smali instruction in a dex file in the APP to be tested;

sequentially checking static character strings and constant character strings for the content of each smali instruction by using class dimension to obtain each HTTP address contained in the static character strings and constant character strings;

and generating an HTTP address set according to each HTTP address.

The method comprises the steps that a dex file is an executable file of an Android system, after an application program in an APK format of the Android system is compiled, program codes (including codes in an integrated SDK) are compiled into the dex file, the dex file exists in the APK, and related resources such as character strings, pictures and the like which are cited in the codes are packaged in the APK in a specific format; smali is a disassembler implementation for Dalvik (virtual machine under the Android system), and the assembler tool can assemble smali code into dex files.

Therefore, aiming at the APP to be tested existing in the APK format, the dex file is disassembled into the smali code, then each smali instruction in the smali code can be traversed according to the common dimension size in the class code language, and the static character string and the constant character string are emphasized to be checked, so that each HTTP address can be comprehensively and completely found.

Step 302: constructing and obtaining an SDK knowledge base according to the corresponding relation between each SDK and each HTTP address in the corresponding HTTP address set;

based on step 301, this step aims at constructing, by the execution body, an SDK knowledge base according to the correspondence between each SDK and each HTTP address in the HTTP address set corresponding to each SDK. The concrete expression form of the SDK knowledge base is not current, and because the SDK knowledge base is essentially a set of corresponding relations, the carrier capable of recording a plurality of corresponding relations can be used for constructing the SDK knowledge base, such as a knowledge graph.

It should be noted that, in very special cases, the HTTP address sets corresponding to different SDKs may include the same target HTTP address, which is usually the same as another HTTP address due to the recognition and entry errors occurring during the process of traversing and searching for the HTTP address. This problem may be solved as much as possible for this case, including but not limited to any of the following ways, to avoid interference with determining the source SDK due to this case:

firstly, initiating a replacement request aiming at a target HTTP address through a first preset path; that is, the manager manually performs replacement by the replacement request;

Secondly, initiating an error verification request aiming at the target HTTP address through a second preset path, namely manually intervening by initiating the error verification request, and determining whether the target HTTP address enters an error or not by combining an actual code.

Step 303: acquiring the actual flow of an application program to be tested;

step 304: extracting an actual HTTP address from the actual flow;

the above steps 303-304 are substantially identical to the steps 201-202 shown in fig. 2, and only the HTTP address selected in step 304 is adaptively adjusted to the actual HTTP address according to the present embodiment, and the content of the same parts is referred to the corresponding parts of the previous embodiment, which is not described herein.

Step 305: determining an actual SDK corresponding to an actual HTTP address extracted from the actual traffic by using an SDK knowledge base;

step 306: determining the actual SDK as a source SDK for generating the actual traffic;

based on step 304, step 305 is to determine an actual SDK corresponding to the actual HTTP address by the execution body using the correspondence recorded in the SDK knowledge base, and then determine the actual SDK as the source SDK that generated the actual traffic by step 306.

Step 307: judging whether the source SDK is a third party SDK, if so, executing a step 308, otherwise, jumping to a step 306 to continuously judge whether other source SDKs are third party SDKs;

Based on step 306, this step is intended to determine whether the source SDK determined in step 306 is a third party SDK, so as to select an appropriate processing branch according to the determination result. Specifically, determining whether an SDK is a third-party SDK may be performed in a variety of ways, for example, package name, version number, developer information, vendor information, etc. all parameters that may be used to distinguish the first-party SDK from the third-party SDK are not specifically limited herein.

Step 308: determining an actual privacy risk level of the actual flow;

the present step is based on the determination result in step 307 that the source SDK is the third party SDK, and aims to determine, by the execution subject, the actual privacy risk level of the actual traffic generated by the third party SDK. Specifically, determining the actual privacy risk level according to the content of the actual flow may be performed in various manners, for example, determining whether the actual flow includes personal privacy data of the user, especially, personal privacy data obtained by the APP to be tested is not authorized, and whether the actual flow includes some privacy data marked as sensitive data or not may also be determined, and specific privacy risk level setting may also be reasonably set according to an actual application scenario, which is not limited specifically herein.

Step 309: judging whether the actual privacy risk level is smaller than a preset level, if so, executing the step 310, otherwise, executing the step 311;

based on step 308, this step aims to determine whether the APP to be tested meets the security privacy requirement by comparing the magnitude relation between the actual privacy risk level and the preset level. The preset level is a critical level for measuring whether the application program to be tested meets the safety privacy requirement.

Step 310: returning a notice that the application program to be tested meets the safety privacy requirement;

the step is based on the fact that the actual privacy risk level is smaller than the preset level in the judgment result of step 309, which means that the actual privacy risk level is smaller and there is a smaller privacy risk, so that a notification that the APP to be tested meets the security privacy requirement will be returned, and the returned object may be the requester that initiates whether the APP to be tested meets the security privacy requirement.

Step 311: and returning a notice that the application program to be tested does not meet the safety privacy requirement.

The step is based on the fact that the actual privacy risk level is not less than the preset level in the judgment result of step 309, and the fact that the actual privacy risk level is large and the large privacy risk exists is explained, so that a notification that the APP to be tested does not meet the safety privacy requirement is returned, and the returned object can be a requester for initiating whether the APP to be tested meets the safety privacy requirement or not.

Furthermore, unqualified labels can be added to the to-be-tested APP with the actual privacy risk level not smaller than the preset level, and abnormal behaviors of the to-be-tested APP in other aspects can be collected as much as possible by recording other safety detection information of all to-be-tested APP with the unqualified labels.

On the basis of having the full beneficial effects of the previous embodiment, the embodiment provides a specific implementation manner of taking the HTTP address as the characteristic character string through the

steps

301 and 302, facilitates subsequent use through the whole of being constructed as the SDK knowledge base, and simultaneously provides a scheme for further aiming at whether the source SDK is a third party SDK and judging whether the APP to be tested meets the safety privacy requirement or not and a scheme for judging whether the APP to be tested meets the safety privacy requirement or not through the steps 307 to 311, and expands the whole scheme to the field of determining whether the APP to be tested meets the safety privacy requirement or not.

It should be noted that, in this embodiment, a specific implementation manner using the HTTP address as the feature string is provided through

steps

301 and 302, and the schemes provided through steps 307 to 311 for further aiming at whether the source SDK is a third party SDK and determining whether the APP to be tested meets the security privacy requirement or not, may be separately generated with the process 200 shown in fig. 2 to form separate embodiments, where no cause and effect and no dependency relationship exist between the two embodiments, and this embodiment exists only as a preferred embodiment in which two portions of preferred schemes exist simultaneously.

In order to deepen understanding, the present application further provides a specific implementation scheme in combination with a specific application scenario, and in this embodiment, three components of the SDK knowledge base, the APK analyzer and the flow analyzer are designed in combination with a specific application scenario, and the relationship between the three components can be referred to as a schematic diagram shown in fig. 4.

The SDK knowledge base records the corresponding relation between a plurality of SDKs and each HTTP address extracted from the actual codes (namely, the code characteristics characterized as characteristic character strings), and can identify which SDK belongs to according to the characteristic character strings;

and the APK analyzer is used for analyzing resources (including a management file, a character string resource and the like) and binary programs (dex files) in the APK to be detected and identifying program codes in the APK to be detected and resource character strings used by the program codes. In the analysis process, all character string constants used by the program are detected, whether the character string is an HTTP address is analyzed, and the SDK corresponding to the HTTP address is determined through the corresponding relation recorded in the SDK knowledge base while the HTTP address is found and recorded. Finally, obtaining a result of an SDK used in the APK to be tested and an HTTP address set corresponding to the SDK;

and the traffic analyzer is used for identifying whether the HTTP address corresponding to a certain SDK appears in the actual traffic of the APK to be tested, namely analyzing the traffic generated by using the HTTP address set of the certain SDK in the APK to be tested when the certain SDK is called and executed, analyzing whether the traffic appears in the HTTP address set recorded with the address set corresponding to the certain SDK, and if so, further determining which SDK the traffic is generated by, namely the traffic comes from the SDK. Specifically, this may be achieved by attaching source information of the corresponding source SDK to each traffic.

The following is a specific implementation scheme for each part:

SDK knowledge base: and collecting SDKs stored on SDKs and a github (a code hosting website) provided by a known company externally, and extracting package name characteristics of the SDKs through a technical means. Extracting SDK package name features can be accomplished in batch based on APK parsing capability provided by an android tool (a tool for APK). Furthermore, as the method can extract the package name features mainly related to the SDK, the security SDK itself can use other class libraries, and the results at the moment can possibly have the features of other SDKs, so that the method also needs to manually combine the whole feature library to check and exclude the features of non-SDKs;

APK analyzer: the APK will compile the compiled program code (including the code in the integrated SDK) into a dex file, and the dex file exists in the APK, and related resources, such as character strings, pictures, etc. referenced in the code will also be packaged in the APK in a specific format. And the APK analyzer analyzes and identifies a smali instruction in the dex, sequentially checks all used static character strings and constant character strings in class dimension, and analyzes HTTP addresses in the static character strings and the constant character strings. After finding the HTTP address, the SDK knowledge base identifies which SDK the address belongs to and records the result. Finally, generating a flow characteristic corresponding to the SDK, wherein the characteristic content is the HTTP address of the request;

Flow analyzer: after the flow generated by the application is obtained through the packet capturing program, the flow analyzer uses the SDK flow characteristics analyzed by the APK analyzer to conduct characteristic comparison on the flow. If a flow hits a feature, it can be determined that the flow was generated by the SDK corresponding to the feature.

Compared with the prior art, the scheme provided by the embodiment is based on the code features which can be uniquely represented in the flow by different SDKs, namely the feature character strings are taken as the recognition basis, the SDK knowledge base constructed based on the corresponding relation between the SDKs and the feature character strings can analyze the APKs to automatically acquire the features of the flow generated by the SDKs, manual analysis is not needed, and therefore the time consumption is extremely short. Meanwhile, the latest feature can be obtained in each detection based on the characteristics of the code features, and the problem that the flow feature change cannot be identified due to the fact that the SDK replaces the requested domain name is avoided. The time and labor cost are low, and the method can support mass detection.

With further reference to fig. 5, as an implementation of the method shown in the foregoing figures, the present application provides an embodiment of an apparatus for determining a source of flow generation, where the embodiment of the apparatus corresponds to the embodiment of the method shown in fig. 2, and the apparatus is particularly applicable to various electronic devices.

As shown in fig. 5, the apparatus 500 for determining a flow generation source of the present embodiment may include: an actual flow acquisition unit 501, an actual feature string extraction unit 502, and a source SDK determination unit 503. Wherein, the actual flow obtaining unit 501 is configured to obtain an actual flow of the application program to be tested; an actual feature string extraction unit 502 configured to extract an actual feature string from the actual traffic; a source SDK determining unit 503 configured to determine a source SDK that generates an actual flow from the actual feature string; wherein, the corresponding relation between each SDK and the characteristic character string contained in the actual code is recorded in advance.

In the present embodiment, in the apparatus 500 for determining a traffic generation source: the specific processing of the actual flow obtaining unit 501, the actual feature string extracting unit 502, and the source SDK determining unit 503 and the technical effects thereof may refer to the relevant descriptions of steps 201 to 203 in the corresponding embodiment of fig. 2, and are not repeated herein.

In some optional implementations of the present embodiment, the apparatus 500 for determining a traffic generating source may further include: the SDK knowledge base construction unit is configured to construct an SDK knowledge base according to the corresponding relation between each SDK and the characteristic character strings contained in the actual codes of the SDK; and the source SDK determination unit may include: a source SDK knowledge base determination subunit configured to determine a source SDK that generates actual traffic based on the actual feature string and the SDK knowledge base.

In some optional implementations of the present embodiment, the SDK knowledge base construction unit may include: an HTTP address set determination subunit configured to determine an HTTP address set contained therein from the actual code of each SDK; the SDK knowledge base construction subunit is configured to construct an SDK knowledge base according to the corresponding relation between each SDK and each HTTP address in the HTTP address set corresponding to each SDK; and the source SDK knowledge base determination subunit is further configured to: determining an actual SDK corresponding to an actual HTTP address extracted from the actual traffic by using an SDK knowledge base; the actual SDK is determined as the source SDK that generated the actual traffic.

In some optional implementations of the present embodiment, the HTTP address set determination subunit may be further configured to: identifying a smali instruction in a dex file in an application program to be tested; sequentially checking static character strings and constant character strings for the content of each smali instruction by using class dimension to obtain each HTTP address contained in the static character strings and constant character strings; and generating an HTTP address set according to each HTTP address.

In some optional implementations of this embodiment, when the HTTP address sets corresponding to the different SDKs respectively include the same target HTTP address, the apparatus 500 for determining a source of traffic generation may further include: a replacement request initiating unit configured to initiate a replacement request for a target HTTP address through a first preset path; or an error-verification-request-initiating unit configured to initiate an error verification request for the target HTTP address through the second preset path.

In some optional implementations of the present embodiment, the apparatus 500 for determining a traffic generating source may further include: an actual privacy risk level determining unit configured to determine an actual privacy risk level of the actual traffic in response to the source SDK belonging to the third party SDK; the notification returning unit is configured to return a notification that the application program to be tested meets the safety privacy requirement when the actual privacy risk level is smaller than the preset level; and the notification returning unit is configured to return a notification that the application program to be tested does not meet the safety privacy requirements when the actual privacy risk level is not less than the preset level.

In some optional implementations of the present embodiment, the apparatus 500 for determining a traffic generating source may further include: the disqualified label attaching unit is configured to attach disqualified labels to the application program to be tested, the actual privacy risk level of which is not less than the preset level; and the other security detection information recording unit is configured to record other security detection information of all the application programs to be tested, to which the unqualified labels are attached.

The present embodiment is different from the method for determining a source SDK based on the traffic characteristics of each SDK given in the prior art, in that the apparatus for determining a traffic generation source provided in the present embodiment selects a characteristic string capable of more accurately associating the SDK with the traffic generated by the SDK, where the characteristic string is a string of traffic generated during the execution of the actual code and the actual code of the SDK, that is, the present embodiment provides an apparatus capable of determining a source SDK based on the code characteristics of each SDK, where the code characteristics have a lower frequency of change than the traffic characteristics and the correspondence is easier to collect and update, and capable of more accurately determining a source SDK generating an actual traffic.

According to embodiments of the present application, an electronic device and a computer-readable storage medium are also provided.

Fig. 6 illustrates a block diagram of an electronic device suitable for implementing a method for determining a traffic generation source according to an embodiment of the present application. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular telephones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be exemplary only, and are not meant to limit implementations of the application described and/or claimed herein.

As shown in fig. 6, the electronic device includes: one or more processors 601, memory 602, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The various components are interconnected using different buses and may be mounted on a common motherboard or in other manners as desired. The processor may process instructions executing within the electronic device, including instructions stored in or on memory to display graphical information of the GUI on an external input/output device, such as a display device coupled to the interface. In other embodiments, multiple processors and/or multiple buses may be used, if desired, along with multiple memories and multiple memories. Also, multiple electronic devices may be connected, each providing a portion of the necessary operations (e.g., as a server array, a set of blade servers, or a multiprocessor system). One processor 601 is illustrated in fig. 6.

Memory 602 is a non-transitory computer-readable storage medium provided herein. The memory stores instructions executable by the at least one processor to cause the at least one processor to perform the methods provided herein for determining a source of traffic generation. The non-transitory computer readable storage medium of the present application stores computer instructions for causing a computer to perform the method provided herein for determining a flow generation source.

The memory 602 is a non-transitory computer readable storage medium, and may be used to store a non-transitory software program, a non-transitory computer executable program, and modules, such as program instructions/modules corresponding to the method for determining a source of traffic generation in the embodiment of the present application (e.g., the actual traffic acquisition unit 501, the actual feature string extraction unit 502, and the source SDK determination unit 503 shown in fig. 5). The processor 601 executes various functional applications of the server and data processing by running non-transitory software programs, instructions and modules stored in the memory 602, i.e., implements the method for determining a traffic generation source in the above-described method embodiments.

The memory 602 may include a storage program area and a storage data area, wherein the storage program area may store an operating system, at least one application program required for a function; the storage data area may store various types of data created by the electronic device when executing the method for determining the traffic generation source, and the like. In addition, the memory 602 may include high-speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory 602 optionally includes memory remotely located relative to processor 601, which may be connected via a network to an electronic device adapted to perform the method for determining the source of traffic generation. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The electronic device adapted to perform the method for determining a traffic generating source may further comprise: an input device 603 and an output device 604. The processor 601, memory 602, input device 603 and output device 604 may be connected by a bus or otherwise, for example in fig. 6.

The input device 603 may receive input numeric or character information and generate key signal inputs related to user settings and function control of an electronic device suitable for performing the method for determining a source of flow generation, such as a touch screen, keypad, mouse, trackpad, touch pad, pointer stick, one or more mouse buttons, trackball, joystick, or like input device. The output means 604 may include a display device, auxiliary lighting means (e.g., LEDs), tactile feedback means (e.g., vibration motors), and the like. The display device may include, but is not limited to, a Liquid Crystal Display (LCD), a Light Emitting Diode (LED) display, and a plasma display. In some implementations, the display device may be a touch screen.

Various implementations of the systems and techniques described here can be realized in digital electronic circuitry, integrated circuitry, application specific ASIC (application specific integrated circuit), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs, the one or more computer programs may be executed and/or interpreted on a programmable system including at least one programmable processor, which may be a special purpose or general-purpose programmable processor, that may receive data and instructions from, and transmit data and instructions to, a storage system, at least one input device, and at least one output device.

These computing programs (also referred to as programs, software applications, or code) include machine instructions for a programmable processor, and may be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, apparatus, and/or device (e.g., magnetic discs, optical disks, memory, programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal used to provide machine instructions and/or data to a programmable processor.

To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to a user; and a keyboard and pointing device (e.g., a mouse or trackball) by which a user can provide input to the computer. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic input, speech input, or tactile input.

The systems and techniques described here can be implemented in a computing system that includes a background component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such background, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), wide Area Networks (WANs), and the internet.

The computer system may include a client and a server. The client and server are typically remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

Different from the method for determining the source SDK based on the flow characteristics of each SDK provided by the prior art, the present embodiment selects the characteristic character string capable of more accurately correlating the SDK with the flow generated by the SDK through the technical scheme, and the characteristic character string is the character string of the flow generated in the execution process of the actual code and the actual code of the SDK, that is, the present embodiment provides a method capable of determining the source SDK based on the code characteristics of each SDK, the code characteristics have lower change frequency compared with the flow characteristics, the correspondence is easier to collect, update and maintain, and the source SDK capable of more accurately determining the actual flow can be determined.

It should be appreciated that various forms of the flows shown above may be used to reorder, add, or delete steps. For example, the steps described in the present application may be performed in parallel, sequentially, or in a different order, provided that the desired results of the technical solutions disclosed in the present application can be achieved, and are not limited herein.

The above embodiments do not limit the scope of the application. It will be apparent to those skilled in the art that various modifications, combinations, sub-combinations and alternatives are possible, depending on design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present application are intended to be included within the scope of the present application.

Claims

1. A method for determining a source of traffic generation, comprising:

acquiring the actual flow of an application program to be tested;

extracting an actual characteristic character string from the actual flow; the actual characteristic character string is a character string which represents SDK code characteristics in the actual flow; the actual characteristic character string at least comprises an HTTP address which appears in the actual code of the SDK, and the HTTP address exists in the same form in the actual code and the actual traffic; wherein each SDK has added the actual characteristic character string when packaged, and the actual characteristic character string appears at a specific position when the SDK is called;

Determining a source SDK for generating the actual flow according to the actual characteristic character string; wherein, the corresponding relation between each SDK and the characteristic character strings contained in the actual codes is recorded in advance;

further comprises:

according to the corresponding relation between each SDK and the characteristic character strings contained in the actual codes, constructing and obtaining an SDK knowledge base, wherein the SDK knowledge base is constructed and obtained based on the corresponding relation between each SDK and each HTTP address in the HTTP address set corresponding to each SDK; and

the determining the source SDK for generating the actual flow according to the actual characteristic character string comprises the following steps: determining a source SDK for generating the actual flow according to the actual characteristic character string and the SDK knowledge base;

wherein the HTTP address set is determined based on the steps of: identifying a smali instruction in a dex file in the application program to be tested; sequentially checking static character strings and constant character strings for the content of each smali instruction by using class dimension to obtain each HTTP address contained in the static character strings and constant character strings; and generating an HTTP address set according to each HTTP address.

2. The method of claim 1, wherein constructing an SDK knowledge base according to a correspondence between each SDK and a feature string included in an actual code thereof, comprises:

Determining an HTTP address set contained in each SDK according to the actual code of each SDK;

constructing and obtaining the SDK knowledge base according to the corresponding relation between each SDK and each HTTP address in the corresponding HTTP address set; and

the determining the source SDK for generating the actual traffic according to the actual characteristic character string and the SDK knowledge base comprises the following steps:

determining an actual SDK corresponding to an actual HTTP address extracted from the actual traffic by using the SDK knowledge base;

and determining the actual SDK as a source SDK for generating the actual traffic.

3. The method of claim 2, when the HTTP address sets respectively corresponding to the different SDKs include the same target HTTP address, further comprising:

initiating a replacement request for the target HTTP address through a first preset path; or (b)

And initiating an error verification request for the target HTTP address through a second preset path.

4. A method according to any one of claims 1 to 3, further comprising:

determining an actual privacy risk level of the actual traffic in response to the source SDK belonging to a third party SDK;

when the actual privacy risk level is smaller than a preset level, returning a notification that the application program to be tested meets the safety privacy requirement;

And when the actual privacy risk level is not less than the preset level, returning a notification that the application program to be tested does not meet the safety privacy requirement.

5. The method of claim 4, further comprising:

attaching an unqualified label to the application program to be tested, the actual privacy risk level of which is not less than the preset level;

recording other security detection information of all the application programs to be tested, which are attached with the disqualified labels.

6. An apparatus for determining a flow generating source, comprising:

an actual flow obtaining unit configured to obtain an actual flow of an application program to be tested;

an actual feature string extraction unit configured to extract an actual feature string from the actual flow rate; the actual characteristic character string is a character string which represents SDK code characteristics in the actual flow; the actual characteristic character string at least comprises an HTTP address which appears in the actual code of the SDK, and the HTTP address exists in the same form in the actual code and the actual traffic; wherein each SDK has added the actual characteristic character string when packaged, and the actual characteristic character string appears at a specific position when the SDK is called;

A source SDK determining unit configured to determine a source SDK that generates the actual traffic from the actual feature string; wherein, the corresponding relation between each SDK and the characteristic character strings contained in the actual codes is recorded in advance;

further comprises:

the SDK knowledge base construction unit is configured to construct an SDK knowledge base according to the corresponding relation between each SDK and the characteristic character strings contained in the actual codes of the SDK knowledge base, wherein the SDK knowledge base is constructed based on the corresponding relation between each SDK and each HTTP address in the corresponding HTTP address set; and

the source SDK determination unit includes:

a source SDK knowledge base determination subunit configured to determine a source SDK that generates the actual traffic from the actual feature string and the SDK knowledge base;

7. The apparatus of claim 6, wherein the SDK knowledge base construction unit comprises:

An HTTP address set determination subunit configured to determine an HTTP address set contained therein from the actual code of each SDK;

the SDK knowledge base construction subunit is configured to construct the SDK knowledge base according to the corresponding relation between each SDK and each HTTP address in the HTTP address set corresponding to each SDK; and

the source SDK knowledge base determination subunit is further configured to:

8. The apparatus of claim 7, when the HTTP address sets respectively corresponding to the different SDKs include the same target HTTP address, further comprising:

a replacement request initiating unit configured to initiate a replacement request for the target HTTP address through a first preset path; or (b)

An error verification request initiating unit configured to initiate an error verification request for the target HTTP address through a second preset path.

9. The apparatus of any of claims 6 to 8, further comprising:

an actual privacy risk level determining unit configured to determine an actual privacy risk level of the actual traffic in response to the source SDK belonging to a third party SDK;

The notification returning unit is configured to return a notification that the application program to be tested meets the safety privacy requirement when the actual privacy risk level is smaller than a preset level;

and the notification returning unit is configured to return a notification that the application program to be tested does not meet the safety privacy requirement when the actual privacy risk level is not less than the preset level.

10. The apparatus of claim 9, further comprising:

a reject label attaching unit configured to attach a reject label to the application to be tested, for which the actual privacy risk level is not less than the preset level;

and the other security detection information recording unit is configured to record other security detection information of all the application programs to be tested, to which the disqualified labels are attached.

11. An electronic device, comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein, the liquid crystal display device comprises a liquid crystal display device,

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method for determining a traffic generating source of any one of claims 1-5.

12. A non-transitory computer readable storage medium storing computer instructions for causing the computer to perform the method for determining a flow generation source of any of claims 1-5.

13. A computer program product comprising a computer program which, when executed by a processor, implements the method according to any of claims 1-5.