Vulnerability hunting method, device, readable storage medium and computer program product

Abstract

This application discloses a vulnerability investigation method, apparatus, readable storage medium, and computer program product, relating to the field of vulnerability type identification technology. The method includes: acquiring a compatibility data packet and / or version data packet for an application; reading an application list corresponding to the application, distinguishing all application versions under different operating environment types, and associating application versions under different operating environment types in pairs to generate compatibility association pairs; based on each compatibility association pair, filtering the compatibility data packet and / or the version data packet to obtain a corresponding data packet set; and determining whether the application has a vulnerability based on the difference in the number of data encapsulation format embeddings between the associated version number data pairs within each data packet set. The solution of this application solves the problems of difficulty in locating vulnerabilities in incrementally updated application vulnerabilities, insufficient root cause detection, inability to investigate cross-linked vulnerabilities, and lack of real-time experience updates in the prior art.

Description

Technical Field

[0001] This application relates to the field of vulnerability type identification technology, specifically to a vulnerability investigation method, apparatus, readable storage medium, and computer program product. Background Technology

[0002] In existing technologies, to ensure application availability and connectivity, continuous vulnerability screening and detection are required during the development of basic and updated versions of the application. However, for incremental updates, if only the updated content is screened for vulnerabilities, it is impossible to effectively locate vulnerabilities or detect root causes. Furthermore, existing vulnerability detection and scanning methods cannot perform cross-functional vulnerability screening; they can only scan for vulnerabilities based on single API interfaces, lacking real-time learning mechanisms and failing to provide real-time updates and iterations of scanning features and experience. Summary of the Invention

[0003] At least one embodiment of this application provides a vulnerability investigation method, apparatus, readable storage medium, and computer program product to address the problems in the prior art, such as difficulty in locating incremental update application vulnerabilities, insufficient root cause detection, inability to investigate cross-linked vulnerabilities, and lack of real-time experience updates.

[0004] To solve the above-mentioned technical problems, this application is implemented as follows:

[0005] Firstly, embodiments of this application provide a vulnerability detection method, including:

[0006] Obtain the application's compatibility data package and / or version data package;

[0007] Read the application list corresponding to the application, distinguish all application versions under different operating environment types, associate the application versions under different operating environment types in pairs, and generate compatible association pairs;

[0008] Based on each of the compatibility association pairs, the compatible data packets and / or the version data packets are filtered to obtain the corresponding data packet set;

[0009] The existence of vulnerabilities in the application is determined based on the difference in the number of data encapsulation format embeddings between the associated version number data pairs within each data packet set.

[0010] Optionally, determining whether the application has vulnerabilities based on the difference in the number of data encapsulation format embeddings between the associated version number data pairs within each data packet set includes:

[0011] Based on the difference in the number of data encapsulation format embeddings between the associated version number data pairs within each data packet set, the sum of incremental difference strengths is accumulated, and a difference counter is calculated.

[0012] The ratio of the sum of incremental difference intensities to the difference counter is used to determine the difference intensity relationship of the application under different operating environment types;

[0013] Based on the first preset threshold and the difference strength relationship, the versions corresponding to the application are grouped, and based on the communication anomaly information of the application, it is determined whether the application has vulnerabilities.

[0014] Optionally, based on a first preset threshold and the relationship of difference intensity, the versions corresponding to the applications are grouped, and based on the communication anomaly information of the applications, it is determined whether the applications have vulnerabilities, including:

[0015] The difference intensity relationship is divided based on a first preset threshold to obtain a first incremental version group with a difference intensity less than the first preset threshold and a second incremental version group with a difference intensity greater than or equal to the first preset threshold.

[0016] The frequency of communication interruptions and the number of response data packets containing version compatibility error identifiers of the application are obtained, and the frequency of communication interruptions and the number of response data packets containing version compatibility error identifiers are used as communication anomaly information of the application.

[0017] Based on the communication anomaly information, traverse the first incremental version group and the second incremental version group, and filter out the root cause interruption version pair and the incremental software version pair from the group;

[0018] Based on the root cause interruption version pair and the incremental software version pair, the vulnerability type of the application is determined to be either a crosslink vulnerability or a single-line vulnerability.

[0019] Optionally, based on the root cause interruption version pair and the incremental software version pair, the vulnerability type of the application is determined to be a crosslink vulnerability or a single-thread vulnerability, including:

[0020] Extract the disordered characters from the binary files corresponding to the root cause interruption version pair and the incremental software version pair, and parse them to obtain the corresponding standard compilation instruction pairs;

[0021] The standard compilation instruction pairs are subjected to race condition judgment to determine whether there is a resource race relationship. If there is a resource race relationship, the race dependency type corresponding to the resource race relationship is distinguished.

[0022] Based on the competition dependency type, if the competition dependency type is a static competition dependency, then the permission mapping relationship between the standard compilation instruction pairs corresponding to the root interrupt version pair and the incremental software version pair is backtracked and verified; if the competition dependency type is a dynamic competition dependency, then the consistency of the compilation complementary order between the root interrupt version pair and the incremental software version pair is backtracked and verified.

[0023] If the backtracking verification is abnormal, for backtracking abnormalities corresponding to static competitive dependencies, the corresponding matching threshold is updated and the steps of random character extraction, standard compilation instruction pair parsing, and competition condition judgment are re-executed; for backtracking abnormalities corresponding to dynamic competitive dependencies, versions are randomly sampled from the two incremental version groups, the compilation instructions of the sampled versions are extracted, and competition condition judgment is performed with the original set of standard compilation instructions.

[0024] Based on the judgment result corresponding to the competition condition, the vulnerability type of the application is determined to be either a cross-link vulnerability or a single-line vulnerability.

[0025] Optionally, the disordered characters in the binary files corresponding to the root cause interruption version pair and the incremental software version pair are extracted, and the corresponding standard compilation instruction pairs are parsed to obtain them, including:

[0026] Obtain the binary files corresponding to the root cause interruption version pair and the incremental software version pair, respectively.

[0027] Locate and extract out-of-order character fragments in the binary file caused by differences in the compilation environment;

[0028] Generate the standard compilation instruction sequences corresponding to the root cause interruption version pair and the incremental software version pair, respectively;

[0029] The disordered character fragments are matched with the standard compilation instruction sequence to obtain the standard compilation instruction pairs corresponding to each disordered character fragment; wherein, the standard compilation instruction pairs corresponding to the root interruption version pair and the incremental software version pair are summarized to form two sets of standard compilation instruction pairs.

[0030] Optionally, the standard compilation instruction pairs are subjected to race condition judgment to determine whether a resource race relationship exists. If a resource race relationship exists, the race dependency type corresponding to the resource race relationship is distinguished, including:

[0031] Extract the resource dependencies corresponding to each instruction in the two sets of standard compiler instruction pairs to form two resource dependency sets;

[0032] By comparing the resource access methods of each instruction in the two resource dependency sets, if there is a write operation that accesses the same resource, then a resource contention relationship is identified; otherwise, no resource contention relationship is identified.

[0033] If resource contention exists, the type of contention dependency corresponding to the resource contention relationship is distinguished according to the method of determining the instruction execution order; among them, the execution order is determined at compile time and the resource access state is known, which is static contention dependency, and the execution order is affected by external conditions or the program runtime state, which is dynamic contention dependency.

[0034] Optionally, obtain the application's compatibility data package and / or version data package, including:

[0035] Obtain the data exchange packets generated by communication between different versions of the same application running under different operating environment types;

[0036] The data interaction packets are filtered for version consistency to obtain incremental update data packets of the same version;

[0037] Based on the incremental update data packet, and according to the preset compatibility judgment rules and module inclusion status, the compatible data packet and / or the version data packet are obtained by classification and parsing.

[0038] The compatible data packet is a set of data interaction packets that determine the compatibility between the sender version and the receiver version after the operating environment mapping; the version data packet is a set of data interaction packets that include usage module identifiers that have not been pre-included.

[0039] Secondly, embodiments of this application provide a vulnerability detection device, including:

[0040] The acquisition module is used to acquire the application's compatibility data package and / or version data package;

[0041] The generation module is used to read the application list corresponding to the application, distinguish all application versions under different operating environment types, associate application versions under different operating environment types in pairs, and generate compatible association pairs.

[0042] The first processing module is used to filter the compatible data packets and / or the version data packets based on each of the compatibility association pairs to obtain the corresponding data packet set;

[0043] The second processing module is used to determine whether the application has vulnerabilities based on the difference in the number of data encapsulation format embeddings between the associated version number data pairs in each data packet set.

[0044] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the method as described in any one of the first aspects.

[0045] Fourthly, embodiments of this application provide a computer program product including computer instructions that, when executed by a processor, implement the steps of the method as described in any one of the first aspects.

[0046] Compared with existing technologies, the vulnerability investigation method, apparatus, readable storage medium, and computer program product provided in this application obtain application-compatible data packets and / or version data packets; read the application list corresponding to the application, distinguish all application versions under different operating environment types, associate application versions under different operating environment types in pairs to generate compatibility association pairs. These compatibility association pairs support multi-version linkage investigation, effectively identify cross-linking vulnerabilities, and rely on real-time data streams to dynamically update detection experience; based on each compatibility association pair, filter the compatible data packets and / or version data packets to obtain corresponding data packet sets; calculate the difference in the number of data encapsulation format embeddings between associated version pairs within the set. This difference directly maps to changes in the underlying protocol structure or compatibility gaps caused by version iterations. When the difference value is abnormal, a vulnerability is determined to exist. This mechanism relies on real runtime interaction data to accurately trace the root cause. The solution in this application solves the problems of difficulty in locating incremental update application vulnerabilities, insufficient root cause detection, inability to investigate cross-linking vulnerabilities, and lack of real-time experience updates in existing technologies. Attached Figure Description

[0047] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0048] Figure 1 A flowchart illustrating the vulnerability detection method provided in this application embodiment;

[0049] Figure 2 A schematic diagram illustrating the mapping relationship between platform application versions and the original version provided in this application embodiment;

[0050] Figure 3 A schematic diagram illustrating the grouping of the first incremental version group and the second incremental version group provided in this application embodiment;

[0051] Figure 4 A schematic diagram illustrating the filtering of root cause interruption version pairs and incremental software version pairs provided in this application embodiment;

[0052] Figure 5 A schematic diagram illustrating the entire process of the vulnerability detection method provided in this application embodiment;

[0053] Figure 6 This is a schematic diagram of the vulnerability detection device provided in an embodiment of this application. Detailed Implementation

[0054] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0055] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and are not used to describe a specified order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first" and "second" are generally of the same class, not limited in number; for example, a first object can be one or more. Furthermore, in the specification and claims, "and" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0056] The term "instruction" in this application can be either a direct instruction (or explicit instruction) or an indirect instruction (or implicit instruction). A direct instruction can be understood as one in which the sender explicitly informs the receiver of specific information, the operation to be performed, or the requested result, etc.; an indirect instruction can be understood as one in which the receiver determines the corresponding information based on the instruction sent by the sender, or makes a judgment and determines the operation to be performed or the requested result, etc., based on the judgment result.

[0057] As described in the background section, existing vulnerability detection methods for incrementally updated software versions cannot perform cross-linking investigations or rollbacks. To address at least one of these issues, this application provides a vulnerability investigation method, apparatus, readable storage medium, and computer program product. These methods can reduce or avoid the occurrence of the above situations, discover complex "cross-linking" vulnerabilities caused by the interaction of multiple versions that are difficult to detect with traditional testing, and improve the development efficiency and stability of cross-platform software.

[0058] This application provides a vulnerability detection method, apparatus, readable storage medium, and computer program product. The method and apparatus are based on the same concept, and since the principles by which they solve problems are similar, their implementations can be mutually referenced; repeated details will not be repeated.

[0059] It should be noted that this embodiment takes the simultaneous support of three operating environments—Windows, Linux, and MacOS—by the same application as an example to break down and explain each step of the method. The scope of protection of this invention is not limited to this specific embodiment.

[0060] Please refer to Figure 1 This application provides a vulnerability detection method, including:

[0061] Step 11: Determine the application's compatibility data package and version data package.

[0062] In this application, it is necessary to obtain data interaction packets generated by communication between different version instances of the same application when the application is running under different operating environment types such as Windows, Linux, and MacOS; to perform version consistency filtering on the data interaction packets to obtain incremental update data packets of the same version; and to parse and determine compatible data packets and version data packets based on the incremental update data packets, wherein the compatible data packets are a set of data interaction packets that reflect the normal interaction between versions, and the version data packets are a set of data interaction packets that reflect the actual data interaction situation of each functional module.

[0063] Step 12: Read the application list corresponding to the application, distinguish all application versions under different operating environment types, associate the application versions under different operating environment types in pairs, and generate compatible association pairs.

[0064] Step 13: Based on each of the compatibility association pairs, filter the compatible data packets and / or the version data packets to obtain the corresponding data packet set;

[0065] Step 14: Determine whether the application has vulnerabilities based on the difference in the number of data encapsulation format embeddings between the associated version number data pairs within each data packet set.

[0066] In this embodiment, the application reads a list of all currently used applications, distinguishes between all application versions under three operating environments: Windows, Linux, and macOS, and associates any two version numbers from all application versions to obtain compatibility pairs (each compatibility pair includes a sender version number and a receiver version number). Based on the version numbers in the compatibility pairs, the corresponding compatible data packets and / or data packet sets in the version data packets are filtered out. The difference in the number of data encapsulation format embeddings between the associated version number data pairs within each data packet set is used to determine the strength of the difference relationship between the application and different operating environment types. Furthermore, the strength of the difference relationship is used to determine whether the application has vulnerabilities.

[0067] Optionally, step 11 above includes:

[0068] The system acquires data interaction packets generated by communication between different versions of the same application running under different operating environment types. Each data interaction packet includes at least one of the following: sender application version, receiver target version, sender operating environment type, receiver operating environment type, sender update module list, sent data, response data, and the module used by the data interaction packet; the module used by the data interaction packet belongs to the sender update module list and is also part of the update module list between the current application version and the previous version of the application.

[0069] The data interaction packets are filtered for version consistency to obtain incremental update data packets of the same version;

[0070] Based on the incremental update data packet, and according to the preset compatibility judgment rules and module inclusion status, the compatible data packet and / or the version data packet are obtained by classification and parsing.

[0071] The compatible data packet is a set of data interaction packets that determine the compatibility between the sender version and the receiver version after the operating environment mapping; the version data packet is a set of data interaction packets that include usage module identifiers that have not been pre-included.

[0072] In this embodiment, incremental update data packets of the same application on different platforms or operating environments are collected to parse out: compatibility adaptation data packets (i.e., compatibility data packets) and version embedding capability packets (i.e., version data packets). After the application starts, the application log L is read, and the update module list LM between the current application version V (e.g., version v1.3.0) and the previous application version VP (e.g., version v1.2.5) is parsed out. (Refer to...) Figure 2As shown, for example, taking the application's simultaneous support for Windows, Linux, and macOS as an example, its latest versions on these platforms are: v1.1.0 for Windows, v1.3.0 for macOS, and v0.1.0 for Linux, with each version's functionality corresponding to the original version v0.1.0. The application's backend server collects the data exchange packets TDP between applications in real time. For any data exchange packet TDP[i], its structure is as follows: ;in, Indicates the sender's application version. Indicates the target version of the receiver. Indicates the sender's operating environment type (options: Windows, Linux, MacOS). Indicates the receiver's operating environment type (options: Windows, Linux, MacOS). This indicates that the sender is updating the module list. Indicates sending data. This represents the response data. This indicates the module that uses the data interaction package. The module that uses the data interaction package is a relatively independent group of components or functional units in the application, such as the user module, shopping module, payment module, order module, etc.

[0073] Within the update check period T set by the application, version consistency is obtained. For all incremental update packets of the same version (denoted as TDP') of 1, the version consistency of the data exchange packet TDP[i] recorded by the sender is obtained as follows. : The == operator checks if the two strings are completely identical; if they are identical, it returns 1, otherwise it returns 0. This method checks for inconsistencies, returning 1 if inconsistent and 0 if consistent; the DE method indicates that the sender's application version is being checked. Based on the sender's operating environment type Switch to receiver operating environment type The version after mapping and conversion of the corresponding version.

[0074] Furthermore, based on the incremental update data packet TDP' of the same version, obtain the compatible data packet CA and the version embedding capability packet VB. (1) Initialize the compatible data packet CA and the version embedding capability packet VB as empty sets, and traverse each data interaction packet TDP'[i] in the incremental update data packet TDP' of the same version, and perform the following operations: if their versions are consistent It is 1, and If the data exchange packet is compatible in version, then it is compatible in version; otherwise, it is incompatible. The data exchange packet TDP'[i] is added to the compatible data packet CA. Incompatibility is not considered here. (2) When the data exchange packet TDP'[j] is used by the module... If the version embedding capability package VB does not exist, the data interaction package TDP'[j] will be added to the version embedding capability package VB. Cases where the package already exists will not be considered here.

[0075] After the traversal is complete, the compatibility data package CA (a set of data interaction packages that reflect the normal interaction between versions) and the version data package VB (a set of data interaction packages that reflect the actual data interaction of each functional module) are obtained.

[0076] Optionally, step 14 above includes:

[0077] Based on the difference in the number of data encapsulation format embeddings between the associated version number data pairs within each data packet set, the sum of incremental difference strengths is accumulated, and a difference counter is calculated.

[0078] The ratio of the sum of incremental difference intensities to the difference counter is used to determine the difference intensity relationship of the application under different operating environment types;

[0079] Based on the first preset threshold and the difference strength relationship, the versions corresponding to the application are grouped, and based on the communication anomaly information of the application, it is determined whether the application has vulnerabilities.

[0080] This application reads a list of all currently used applications, distinguishes all application versions under different operating environment types, and associates any two version numbers among all application versions to obtain compatibility association pairs. Each compatibility association pair includes a sender version number and a receiver version number. Based on the version numbers in the compatibility association pairs, the application filters out the corresponding compatible data packets and the data packet sets in the version data packets, and obtains the sum of incremental difference strengths and a difference counter for the data packet sets. Using the ratio of the sum of incremental difference strengths and the difference counter, the application's difference strength relationship under different operating environment types is determined.

[0081] This application compares the data encapsulation strength in compatibility data packets (CA) and version data packets (VB) to obtain the difference in encapsulation strength between different platforms for the same version of the application, which helps to understand the compatibility and differences between versions. It reads a list of all currently used applications, distinguishes all application versions under each operating environment type (e.g., it can clearly distinguish all application versions under Windows, Linux, and MacOS operating environments), and associates any two version numbers in all application versions to form compatibility pairs (denoted as PK). Each compatibility pair contains the sender's version number and the receiver's version number.

[0082] Furthermore, the incremental difference strength of the compatibility association pair for each packet TDP'[i] in the compatible packet CA of PK is calculated. The calculation formula is as follows: ,in, This represents the number of DP data encapsulation formats embedded in the i-th data packet in the compatible data packet CA. This indicates the number of DP data encapsulation formats embedded in the i-th data packet of the version embedding capability package VB. The DP data encapsulation format used in the data interaction packet TDP'[i] represents the data encapsulation format among all data packets generated during the interaction. The data encapsulation format indicates the data being sent during the encapsulation process. or response data Encryption was performed using the asymmetric LTS encryption protocol, and the range of values ​​for i is... min means taking the smaller of the parameters, si means taking the number of elements in the set, when When it is 0, Set it to 0. Set the TDP'[i] of each data packet to 0. Accumulated to the sum of incremental difference in intensity (denoted as ), and at the same time, the difference counter (denoted as Increment by 1; then, iterate through each data packet TDP'[j] in the version data packet VB of the compatibility association pair denoted as PK, repeat the above operation, and accumulate the incremental difference strength of each data packet to 1. Difference counter Synchronous auto-increment.

[0083] Based on the sum of incremental difference intensity With difference counter The ratio of the two factors determines the strength of the difference (denoted as DIF) under different operating environment types. The calculation formula is as follows: ;like When the value is zero, replace it with the minimum non-zero support value to avoid division by zero errors.

[0084] Here, based on a first preset threshold (denoted as threshold A), and combined with the obtained difference intensity relationship, the version pairs corresponding to the application can be grouped to obtain a first incremental version group whose difference intensity satisfies the first preset condition (difference intensity < threshold A) and a second incremental version group whose difference intensity satisfies the second preset condition (difference intensity ≥ threshold A); the application's communication interruption frequency and the number of response data packets containing version compatibility error identifiers are obtained, and the two are used as the application's communication anomaly information; based on the communication anomaly information, the first incremental version group and the second incremental version group are traversed, and the root cause interruption version pairs and incremental software version pairs are selected from the groups.

[0085] It should be noted that the solution in this application can be implemented using the white-box approach of an agent. Its processing logic and processing thinking can be encapsulated as an agent to guide high-level large models to participate in actual business production and application.

[0086] This application extracts disordered characters from the binary files corresponding to the root interrupt version pair and the incremental software version pair, and parses them to obtain the corresponding standard compilation instruction pairs. It then performs race condition judgment on the standard compilation instruction pairs to determine whether a resource race relationship exists. If a resource race relationship exists, it distinguishes the race dependency type corresponding to the resource race relationship. Based on the race dependency type, if it is a static race dependency, it performs a backtracking verification of the permission mapping relationship between the standard compilation instruction pairs corresponding to the root interrupt version pair and the incremental software version pair. If it is a dynamic race dependency, it performs a backtracking verification of the consistency of the compilation complementary order between the root interrupt version pair and the incremental software version pair. If an anomaly is found in the backtracking verification, the matching threshold is updated for static race dependencies, and the relevant steps are re-executed. For the sampled versions of dynamic race dependencies, the race condition judgment is re-performed. Based on the race condition judgment result, it is determined whether the application has a vulnerability.

[0087] Optionally, based on a first preset threshold and the relationship of difference intensity, the versions corresponding to the applications are grouped, and based on the communication anomaly information of the applications, it is determined whether the applications have vulnerabilities, including:

[0088] The difference intensity relationship is divided based on a first preset threshold to obtain a first incremental version group with a difference intensity less than the first preset threshold and a second incremental version group with a difference intensity greater than or equal to the first preset threshold.

[0089] The frequency of communication interruptions and the number of response data packets containing version compatibility error identifiers of the application are obtained, and the frequency of communication interruptions and the number of response data packets containing version compatibility error identifiers are used as communication anomaly information of the application.

[0090] Based on the communication anomaly information, traverse the first incremental version group and the second incremental version group, and filter out the root cause interruption version pair and the incremental software version pair from the group;

[0091] Based on the root cause interruption version pair and the incremental software version pair, the vulnerability type of the application is determined to be either a crosslink vulnerability or a single-line vulnerability.

[0092] In this embodiment, based on a first preset threshold (denoted as threshold A) and combined with the obtained difference strength relationship DIF, the corresponding version pairs of the application are grouped: version pairs with difference strength relationship DIF < threshold A are assigned to the first incremental version group (denoted as G1), and version pairs with difference strength relationship DIF ≥ threshold A are assigned to the second incremental version group (denoted as G2). A schematic diagram of the grouped results can be found in the provided text. Figure 3 As shown. The specific process of obtaining communication anomaly information of the application includes: (1) Communication interruption frequency: monitor the communication process between different versions of the application (PK), record the sending and receiving status of each data packet, count the total number of communication interruption events, and summarize them according to the update check cycle T. Communication interruption frequency between each compatibility pair PK ; ,in, It is the number of interruptions that occur during communication between versions and PK, and T is the update check period. (2) Number of response data packets containing version compatibility error identifiers: Count the total number of data packets containing version compatibility error information identifiers in the response data (RD) corresponding to each version to PK.

[0093] Furthermore, the communication relationships between the software to be detected are obtained again. Based on the intercepted communication interruption frequency, the root cause interruption version pairs BetaE1 and BetaE2 and the incremental software version pairs BetaF1 and BetaF2 are selected from the first incremental version group G1 and the second incremental version group G2, respectively.

[0094] Obtain communication anomaly information for the application, specifically including the frequency of communication interruptions and the number of response packets containing version compatibility error identifiers. Monitor the communication process between different application versions, record the sending and receiving of each data packet, count the total number of communication interruption events, and summarize them according to the update check cycle T to obtain the communication interruption frequency between each compatibility pair PK. ; ,in, This refers to the number of interruptions that occur during communication between versions and PKs, where T is the update check period. The number of response packets containing version compatibility error identifiers is determined by counting the total number of packets containing version compatibility error information identifiers in the response data RD corresponding to each version to the PK.

[0095] Furthermore, refer to Figure 4 As shown, (1) for each version in the first incremental version group G1 Determine the frequency of communication interruptions. :like If the second preset threshold is exceeded (denoted as threshold B), the version will be... The module for using the sender data interaction packet. Record the root cause of the break version pair (denoted as BetaE1); summarize this version pair. If the number of response packets containing version compatibility error flags exceeds a third preset threshold (denoted as threshold C), then the version compatibility error will be removed. The module for using the sender data interaction packet. Add to the root break version pair (denoted as BetaE2).

[0096] (2) For each version in the second incremental version group G2 Perform the same judgment as above: if If the threshold B is exceeded, this version will be modified. The module for using the sender data interaction packet. Record the incremental software version pair (denoted as BetaF1); summarize all response packets containing version compatibility error flags in PK_j for this version pair, and if the number exceeds the threshold C, then delete the version pair. The module for using the sender data interaction packet. Add to the incremental software version pair (denoted as BetaF2). (3) Combine BetaE1 with BetaE2 and BetaF1 with BetaF2 to finally obtain the root interruption version pair (BetaE1, BetaE2) and the incremental software version pair (BetaF1, BetaF2).

[0097] Furthermore, based on the selected root cause interruption version pairs and incremental software version pairs, the vulnerability type of the application is determined to be either a crosslink vulnerability or a single-line vulnerability.

[0098] Optionally, based on the root cause interruption version pair and the incremental software version pair, the vulnerability type of the application is determined to be a crosslink vulnerability or a single-thread vulnerability, including:

[0099] Extract the disordered characters from the binary files corresponding to the root cause interruption version pair and the incremental software version pair, and parse them to obtain the corresponding standard compilation instruction pairs;

[0100] The standard compilation instruction pairs are subjected to race condition judgment to determine whether there is a resource race relationship. If there is a resource race relationship, the race dependency type corresponding to the resource race relationship is distinguished.

[0101] Based on the competition dependency type, if the competition dependency type is a static competition dependency, then the permission mapping relationship between the standard compilation instruction pairs corresponding to the root interrupt version pair and the incremental software version pair is backtracked and verified; if the competition dependency type is a dynamic competition dependency, then the consistency of the compilation complementary order between the root interrupt version pair and the incremental software version pair is backtracked and verified.

[0102] If the backtracking verification is abnormal, for backtracking abnormalities corresponding to static competitive dependencies, the corresponding matching threshold is updated and the steps of random character extraction, standard compilation instruction pair parsing, and competition condition judgment are re-executed; for backtracking abnormalities corresponding to dynamic competitive dependencies, versions are randomly sampled from the two incremental version groups, the compilation instructions of the sampled versions are extracted, and competition condition judgment is performed with the original set of standard compilation instructions.

[0103] Based on the judgment result corresponding to the competition condition, the vulnerability type of the application is determined to be either a cross-link vulnerability or a single-line vulnerability.

[0104] In this embodiment, based on the found BetaE1, BetaE2, BetaF1, and BetaF2, the disordered characters in the SIUD binary files between BetaE1 and BetaE2, and BetaF1 and BetaF2, are first extracted, and the corresponding correct compilation instruction pairs [BetaE1-BetaE2||REA] and [BetaF1-BetaF2||REB] are parsed out. This application analyzes the disordered characters in the SIUD binary files and maps them back to standard compilation instructions, serving as a basis for subsequent repairs or compatibility optimizations. It displays the instruction misalignment locations caused by differences in compilation environments between versions, providing precise targets for subsequent version compatibility repairs.

[0105] The standard compilation instruction pairs obtained from the parsing are judged for competition conditions to determine whether there is a resource competition relationship. If there is a resource competition relationship, the competition dependency type corresponding to the resource competition relationship is distinguished. Based on the above competition dependency type, the corresponding backtracking verification operation is performed: (1) If the competition dependency type is a static competition dependency: the permission mapping relationship between the standard compilation instruction pairs corresponding to the root interruption version pair and the incremental software version pair is backtracked and verified. Specifically, each instruction in the two sets of standard compilation instruction pairs is traversed, and the required permission type (divided into ordinary permission, TLS permission, SUDO permission) is extracted. The permission list is loaded in the order of the instructions and the consecutive identical permissions are merged to obtain two sets of permission rule lists. If the order of the two sets of permission rule lists is consistent, the permission mapping relationship is considered to be a linear mapping and the backtracking verification is not abnormal. Otherwise, the backtracking verification is abnormal. (2) If the competition dependency type is a dynamic competition dependency: the consistency of the compilation complementary order between the root interruption version pair and the incremental software version pair is backtracked and verified. Specifically, the ratio of the number of intersections to the number of unions between the module lists contained in the root interrupt version pair and the module lists contained in the incremental software version pair is calculated (i.e., the consistency of the compilation complementary order). If the consistency is less than the consistency convergence threshold, then there is an anomaly in the backtracking check; otherwise, there is no anomaly in the backtracking check.

[0106] If an anomaly is found in the backtracking check, execute the corresponding anomaly handling steps: (1) Backtracking anomaly corresponding to static competitive dependency: Update the corresponding matching threshold (i.e., edit distance threshold D), the update formula is as follows ,in, This indicates the smaller of the number of sudo permissions in the permission rule lists RA and RB. The shorter of the permission rule list RA and RB is used; after updating the threshold, the steps of extracting disordered characters, parsing standard compilation instructions, and judging race conditions are re-executed. (2) Backtracking anomalies corresponding to dynamic race dependencies: Two versions are randomly sampled from the first incremental version group G1 and the second incremental version group G2 respectively, the compilation instructions of the sampled versions are extracted, and the race conditions are judged against the original set of standard compilation instructions. The race conditions judgment steps are repeated.

[0107] When problems are found in the backtracked content, two BetaE3, BetaE4 and BetaF3, BetaF4 are randomly selected from the first incremental version group G1 and the second incremental version group G2, respectively. Then, they are compared with REA and REB to determine the race condition of the correct compilation instructions corresponding to their out-of-order parts. The conclusion of whether there is a race relationship is obtained. By gaining a deeper understanding of the potential race problems between versions, we can ensure a sustainable and efficient development process in version iteration.

[0108] (1) Randomly select two versions, BetaE3 and BetaE4, from the first incremental version group G1, and randomly select two versions, BetaF3 and BetaF4, from the second incremental version group G2.

[0109] (2) Analyze the newly selected versions BetaE3, BetaE4, BetaF3 and BetaF4, extract the compilation instructions in each version, and form their respective resource dependency sets RE3, RE4, RF3 and RF4. The extracted information includes: variables, memory addresses and files involved in the instructions, permission types and dependencies required for instruction execution.

[0110] (3) Compare the new version of the instructions with the previous instructions to determine the race condition of REA and REB. By comparing the resource dependency set of the new version with the resource dependency set in REA and REB, determine whether there is a resource race. If there is no resource race, check the access method between any two instructions to determine whether there is a race condition. The specific checking method is the same as the checking method mentioned above, and will not be repeated here.

[0111] (4) Based on the results of the competition condition judgment, record the conclusion that a competition relationship has occurred or not. If a competition relationship exists, record the instruction pair and the corresponding version information, form a detailed competition relationship report, and indicate the type of resource being competed and the reason for the competition. If no competition relationship is found, record the independence between instruction pairs and indicate that there is no influence between versions.

[0112] If a competitive relationship exists, it is determined that there is a cross-linking vulnerability between BetaE1, BetaE2 and BetaF1, BetaF2 in their respective resource dependency sets RE3, RE4, RF3 and RF4; otherwise, it is proven that there is a single-line vulnerability between them.

[0113] By determining whether there are associated vulnerabilities, a controllable associated version can be provided for subsequent vulnerability analysis, improving the relevance of input data and avoiding bias in analysis results due to invalid associations.

[0114] (1) By comparing versions and Calculate the strength of the competitive relationship between the two. :make and The competitive relationship is ,Right now: ;in, In the instructions and Returns 1 if there is competition, otherwise returns 0. (2) If If so, a cross-linking vulnerability is confirmed to exist. Recorded as: (3) If This indicates there is no cross-competition, and it is recorded as two single-line vulnerabilities. : ; (4) If a cross-linking vulnerability exists, the document shall describe in detail the specific instruction pair that triggered the cross-linking vulnerability. If no cross-linking vulnerability is found, it shall be clearly marked as a single-line vulnerability, and it shall be stated that there is no mutual influence between the versions. Finally, the selected incremental versions shall be output to the optimized preset vulnerability model for precise analysis of the vulnerability location and cause.

[0115] Optionally, to facilitate vulnerability location and cause analysis, the selected incremental version, including the crosslinking vulnerability, can be analyzed. Or two single-line vulnerabilities Version Compatibility and As input parameters, a specially optimized Gemini model is fed in, and its large model generation capabilities are used to generate analysis results that can be directly read and displayed by researchers.

[0116] Furthermore, the disordered characters in the binary files corresponding to the root cause interruption version pair and the incremental software version pair are extracted, and the corresponding standard compilation instruction pairs are parsed to obtain them, including:

[0117] Obtain the binary files corresponding to the root cause interruption version pair and the incremental software version pair, respectively.

[0118] Locate and extract out-of-order character fragments in the binary file caused by differences in the compilation environment;

[0119] Generate the standard compilation instruction sequences corresponding to the root cause interruption version pair and the incremental software version pair, respectively;

[0120] The disordered character fragments are matched with the standard compilation instruction sequence to obtain the standard compilation instruction pairs corresponding to each disordered character fragment; wherein, the standard compilation instruction pairs corresponding to the root interruption version pair and the incremental software version pair are summarized to form two sets of standard compilation instruction pairs.

[0121] In this embodiment, the SIUD binary files (Sequential Incremental Update Data, i.e., the original data stream of incremental updates between versions) corresponding to the root cause break version pair (BetaE1, BetaE2) and the incremental software version pair (BetaF1, BetaF2) are obtained. Out-of-order character fragments caused by differences in the compilation environment are located and extracted from the SIUD binary files. Out-of-order characters refer to fragments in the binary stream where the order of consecutive bytes is inconsistent with the standard compilation instruction sequence. A sliding window with a fixed scan length LS is used to scan the SIUD file, detect the start and end positions of the out-of-order characters, and extract the first set of out-of-order fragments. (For root interrupt version pairs) and the second out-of-order fragment set CS (for incremental software version pairs), where Based on official compilers (such as MSVC, GCC, etc.), generate the standard compilation instruction sequences corresponding to the root break version pairs (BetaE1, BetaE2) and incremental software version pairs (BetaF1, BetaF2). The extracted disordered character fragments are compared with their corresponding standard compiler instruction sequences. The matching and parsing process yields the standard compiler instruction pairs corresponding to each disordered character fragment: for each disordered fragment... Calculate its relationship with The edit distance of all subsequences (using the Euclidean distance of the binary file) is used to select the standard instruction subsequence with the smallest edit distance. If the minimum edit distance is lower than the threshold D, then s is considered to be... The out-of-order representation, recording the correct compilation instruction pairs (s, Each root cause interrupt version is summarized into a set of all standard compiler instruction pairs, forming the first set of standard compiler instruction pairs. ; Summarize all standard compiler instruction pairs corresponding to incremental software version pairs to form a second set of standard compiler instruction pairs. .

[0122] Furthermore, the standard compiler instruction pairs are subjected to race condition judgment to determine whether a resource race relationship exists. If a resource race relationship exists, the race dependency type corresponding to the resource race relationship is distinguished, including:

[0123] Extract the resource dependencies corresponding to each instruction in the two sets of standard compiler instruction pairs to form two resource dependency sets;

[0124] By comparing the resource access methods of each instruction in the two resource dependency sets, if there is a write operation that accesses the same resource, then a resource contention relationship is identified; otherwise, no resource contention relationship is identified.

[0125] If resource contention exists, the type of contention dependency corresponding to the resource contention relationship is distinguished according to the method of determining the instruction execution order; among them, the execution order is determined at compile time and the resource access state is known, which is static contention dependency, and the execution order is affected by external conditions or the program runtime state, which is dynamic contention dependency.

[0126] In this embodiment, based on the parsed compilation instructions, a race condition judgment is performed on the correct compilation instructions corresponding to the out-of-order portions in [BetaE1-BetaE2||REA] and [BetaF1-BetaF2||REB]. If a race condition exists, it is determined whether it is a static or dynamic race dependency. By analyzing the correct compilation instructions corresponding to the out-of-order instructions, the race conditions are identified and classified into static and dynamic dependencies, providing precise target location for subsequent race elimination and version compatibility optimization. Resource dependencies in the compilation instructions are extracted. Each instruction in the instruction pair [BetaE1-BetaE2||REA] is traversed to extract the resources used in the instructions, including variables, memory addresses and files, and the sender update module list. Modules that require resource and data interaction packages Required system calls and data transmission Response data needs to be written to the directory. The directory where the storage is located forms a set of resource dependencies. Perform the same operation on the instruction pair [BetaF1-BetaF2||REB] to extract the resource dependency set. Identify resource competition relationships and compare them one by one against the resource dependency sets. and The method of accessing instructions, determining whether a race condition exists, for any two instructions and ,like and If two or more instructions access the same resource and one of them is a write operation, then resource contention is identified and the contention is recorded.

[0127] Dependency types are distinguished based on resource contention: By examining whether there is a fixed calling relationship between instructions, if the execution order of two instructions is determined at compile time, and their resource access states are known at compile time, it is considered a static contention dependency, and the dependency relationship is marked as static. Check whether the instruction execution order is affected by external conditions or the program's runtime state. If the execution of instructions depends on conditional statements, loop structures, or multithreaded scheduling, it indicates a dynamic contention dependency, and the dependency relationship is marked as dynamic.

[0128] If resource contention exists, the type of contention dependency corresponding to the resource contention is distinguished based on how the instruction execution order is determined:

[0129] (1) Static competitive dependency: If two instructions that compete with each other have their execution order determined at compile time and their resource access status is known at compile time, then the competitive dependency type corresponding to the resource competition relationship is static competitive dependency.

[0130] (2) Dynamic competitive dependency: If the execution order of two competing instructions is affected by external conditions or program runtime state (such as condition judgment, loop structure, multi-thread scheduling, etc.), then the competitive dependency type corresponding to the resource competition relationship is dynamic competitive dependency.

[0131] Understandably, if the relationship is static and involves competition, further backtracking is performed to determine if there is a linear mapping between the TLS permissions and SUDO permissions between REA and REB. If a linear relationship is confirmed, the following steps are executed: "When there is a problem with the backtracked content, randomly select two BetaE3, BetaE4 and two BetaF3, BetaF4 from the first incremental version group G1 and the second incremental version group G2, and then compare them with REA and REB again to determine the competition condition by comparing the correct compilation instructions corresponding to their out-of-order parts, and then determine whether there is a competition relationship." Otherwise, if the update edit distance is lower than the threshold D, the following steps are executed again: "Extract the out-of-order characters in the binary files corresponding to the root interrupt version pair and the incremental software version pair, and parse them to obtain the corresponding standard compilation instruction pairs."

[0132] If it is a dynamic dependency, then further backtrack to determine the consistency of the complementary compilation order between BetaE1 and BetaF1, and between BetaE2 and BetaF2. If there is a problem with the consistency after backtracking, execute the following steps: "When there is a problem with the backtracked content, randomly select 2 BetaE3, BetaE4 and BetaF3, BetaF4 from the first incremental version group G1 and the second incremental version group G2, and compare them with REA and REB again to determine the race condition of the correct compilation instructions corresponding to their out-of-order parts, and obtain the conclusion of whether there is a race relationship".

[0133] This check can accurately determine the execution permissions of each instruction, thereby ensuring the security and executability of the code in subsequent versions and feature optimizations, and providing a basis for subsequent vulnerability investigation and remediation.

[0134] In one specific implementation, if the dependency relationship is static, the linear mapping between TLS and SUDO permissions between REA and REB is further investigated. Each instruction in the instruction pair REA and REB is traversed, and its required permission type is extracted, categorized into normal permissions and privilege escalation permissions (TLS permissions and SUDO permissions; TLS permissions are for network interface call commands, and SUDO permissions are high-risk permissions, including operations on high-privilege commands such as SUDO and SU in Linux). The permission lists required by the instructions in REA and REB are loaded sequentially (each instruction is loaded one by one, in the following order: 0: no permission required, 1: TLS permission, 2: SUDO permission). Then, consecutive identical permissions are merged to obtain the permission rule lists RA and RB for the instruction pair REA and REB. If the permission lists RA and RB are in the same order, the linear mapping between TLS and SUDO permissions between REA and REB is considered; otherwise, it is determined that the relationship is not linear.

[0135] If it is determined to be a linear mapping, the following steps are performed: "When there is a problem with the backtracked content, randomly select two BetaE3, BetaE4 and two BetaF3, BetaF4 from the first incremental version group G1 and the second incremental version group G2, and compare them with REA and REB again to determine the race condition by comparing the correct compilation instructions corresponding to their out-of-order parts, and then determine whether there is a race relationship."

[0136] If it is determined that the mapping is not linear, and the update edit distance is lower than the threshold D, the step of "extracting the disordered characters in the binary files corresponding to the root interrupt version pair and the incremental software version pair, and parsing to obtain the corresponding standard compilation instruction pair" is re-executed.

[0137] The updated edit distance being below the threshold D' is obtained as follows: ,in, This indicates the smaller of the number of sudo permissions in the permission rule lists RA and RB. This indicates the shorter of the permission rule lists RA and RB.

[0138] In another implementation, if it is a dynamic dependency, the consistency of the complementary compilation order between BetaE1 and BetaF1, and between BetaE2 and BetaF2, is further traced back. If there is a problem after tracing back the consistency, the following steps are performed: "When there is a problem with the traced content, two BetaE3, BetaE4 and two BetaF3, BetaF4 are randomly selected from the first incremental version group G1 and the second incremental version group G2, and they are compared with REA and REB again to determine the race condition of the correct compilation instructions corresponding to their out-of-order parts, so as to obtain the conclusion of whether there is a race relationship."

[0139] If it is a dynamic dependency, obtain BetaE1 and BetaF1, as well as BetaE2 and BetaF2, and obtain the consistency CP of the compile complementary order between BetaE1 and BetaF1, and BetaE2 and BetaF2, as follows:

[0140] ,in, This represents the union of the lists of modules included in a software version. This indicates finding the intersection of the lists of modules included in the software version, where cm represents the number of modules in the list. When the consistency of the complementary order of compilation is inconsistent (CP is less than the consistency convergence threshold, i.e., there is a problem after backtracking), the following steps are executed: "When there is a problem with the backtracked content, randomly select two BetaE3, BetaE4 and two BetaF3, BetaF4 from the first incremental version group G1 and the second incremental version group G2, and compare them with REA and REB again to determine the competition condition for the correct compilation instructions corresponding to their out-of-order parts, and obtain the conclusion of whether there is a competition relationship." Otherwise, the following steps are executed: "If there is a competition relationship, it is determined that there is a crosslink vulnerability between BetaE1, BetaE2 and BetaF1, BetaF2 in their respective resource dependency sets RE3, RE4, RF3 and RF4; if not, it is proven that there is a single-line vulnerability between them."

[0141] In one specific embodiment, reference is made to Figure 5 The diagram shows the complete process of the cross-linking compatibility vulnerability investigation method, which is divided into two main stages: the abnormal platform software search stage and the cross-linking vulnerability investigation stage.

[0142] In the abnormal platform software search phase, the goal of this phase is to locate suspicious version pairs with compatibility issues from massive amounts of interactive data.

[0143] Step 1: Data Acquisition and Analysis. Collect cross-platform or cross-environment interaction data packets, filter to obtain incremental update data, and parse out compatibility data packets (CA) and version data packets (VB). Step 2: Difference Strength Analysis. Construct compatibility association pairs, calculate the incremental difference strength between versions, and finally obtain the difference strength relationship (DIF) under different environments. Step 3: Version Grouping. Based on preset thresholds, divide the versions into a first incremental version group (G1) and a second incremental version group (G2). Step 4: Interruption Version Filtering. Combining communication interruption frequency and the number of error flag data packets, filter out the root cause interruption version pairs (BetaE1 / E2) and incremental software version pairs (BetaF1 / F2) from G1 / G2.

[0144] In the crosslink vulnerability investigation phase, the goal is to determine whether the selected version pairs belong to crosslink vulnerabilities or single-line vulnerabilities. Step 5: Parse standard compiler instruction pairs. Extract out-of-order characters from the target version's binary file and map them to obtain the standard compiler instruction pair sets [E1-E2||REA] and [F1-F2||REB]. Step 6: Race condition identification. Extract the resource dependencies of the instructions, determine whether resource races exist, and distinguish between static and dynamic race dependencies. Step 7: Backtracking verification: Static dependencies: Verify whether the permission mapping is linear; Dynamic dependencies: Verify the consistency of the complementary order of compiler bits; If the verification is abnormal, update the threshold or sampled version and re-perform race condition identification. Step 8: Sampling re-identification. Randomly select a new version from G1 or G2, repeat the race condition identification, and cross-validate the results. Step 9: Vulnerability type determination. Based on the strength of the race relationship, determine whether it is a crosslink vulnerability or a single-line vulnerability. Step 10: Model analysis output: Input the vulnerable version into the optimized large model to generate a precise analysis report on the vulnerability location and cause.

[0145] This application identifies suspicious versions from cross-platform interaction data, distinguishes between cross-linked and single-line vulnerabilities through compilation instructions and competition analysis, and outputs analysis results that can be directly used for remediation.

[0146] This application proposes a novel version incremental difference analysis method based on cross-platform data interaction packet parsing. It reads application log L and parses the update module list LM between the current application version V and the previous application version VP. The application backend server collects data interaction packets TDP between applications in real time. For any data interaction packet TDP[i], it performs platform difference version incremental filtering on the data interaction packet TDP to obtain the same-version incremental update data packet TDP'. Based on the same-version incremental update data packet TDP', it obtains the compatibility data packet CA and the version embedding capability packet VB. It reads the list of all currently used applications and associates any two version numbers pairwise to obtain the compatibility association pair PK. Finally, it obtains the sum of the incremental difference intensity of the compatibility association pair PK. and difference counter Iterate through each data packet TDP'[j] in the version embedded capability package VB, perform the same operation as the previous step, and obtain the incremental difference intensity of each data packet accumulated to... Ultimately, the difference strength relationship DIF between the same version of the application on different platforms was obtained.

[0147] This application proposes a brand-new multi-level screening mechanism for version pairs based on difference intensity and communication interruption frequency. It checks the difference intensity relationship DIF. If DIF < A, the DIF value of the current data packet is added to the first incremental version group G1. If DIF ≥ A, the DIF value of the current data packet is added to the second incremental version group G2. Obtain the communication relationship between the software to be detected, and get the communication interruption frequency between versions of the compatible association pair PK , traverse the first incremental version group G1 and the second incremental version group G2, and analyze the compatible association pairs respectively to screen out the root cause interruption version pairs. In, summarize all response data For data packets containing version compatibility error information identification codes, when the number of data packets exceeds the preset threshold C, the version pair The usage module of the sender data interaction packet in the pair is added to package BetaE2. In, summarize all response data For data packets containing version compatibility error information identification codes, when the number of data packets exceeds the preset threshold C, the version pair The usage module of the sender data interaction packet in the pair , is added to BetaF2. Combine the final sets in pairs to form the root cause interruption version pairs BetaE1, BetaE2 and the incremental software version pairs BetaF1, BetaF2.

[0148] This application covers the entire process of identifying cross-version cross-linking vulnerabilities involving data, code, and permissions. Based on the found BetaE1, BetaE2, BetaF1, and BetaF2, it first extracts out-of-order characters from the SIUD binary files between BetaE1 and BetaE2, and BetaF1 and BetaF2, and parses out the corresponding correct compilation instruction pairs [BetaE1-BetaE2||REA] and [BetaF1-BetaF2||REB]. Based on the parsed compilation instructions, it performs race condition checks on the correct compilation instructions corresponding to the out-of-order parts in [BetaE1-BetaE2||REA] and [BetaF1-BetaF2||REB]. If a race condition exists, it determines whether the race condition is static or dynamic. If it is static, it further traces back to see if there is a linear mapping between the TLS permissions and SUDO permissions between REA and REB. If it is dynamic... If a dependency relationship is found, the consistency of the complementary compilation order between BetaE1 and BetaF1, and between BetaE2 and BetaF2, is further investigated. If a problem is found after investigation, the step of "obtaining a conclusion on whether there is a competition relationship" is executed. If a problem is found in the investigation content, two BetaE3, BetaE4 and two BetaF3, BetaF4 are randomly selected from the first incremental version group G1 and the second incremental version group G2, and they are compared with REA and REB again to determine the competition condition of the correct compilation instructions corresponding to their out-of-order parts. If a competition relationship exists, it is determined that there is a cross-linking vulnerability between BetaE1, BetaE2 and BetaF1, BetaF2 in their respective resource dependency sets RE3, RE4, RF3 and RF4. If not, it is proven that there is a single-line vulnerability between them. Finally, the selected incremental versions are output to the optimized gemini model for precise analysis of the vulnerability location and cause.

[0149] In summary, this application proposes a version incremental difference analysis method based on cross-platform data interaction package parsing. This method enables the system to automatically separate "compatibility and adaptation data packages" and "version embedding capability packages" from massive amounts of interaction data, providing a clean and high-value data foundation for subsequent quantitative analysis. It transforms the compatibility analysis that originally relied on manual testing into a continuous and automated analysis process based on real user interaction data, greatly improving the depth and efficiency of understanding the compatibility status of complex software ecosystems.

[0150] This application proposes a multi-level screening mechanism based on version pairs with varying strength and frequency of communication interruptions. It employs a dual screening model of "static feature analysis + dynamic behavior verification," which significantly improves the accuracy and reliability of vulnerability location and ensures that subsequent in-depth binary analysis can focus on truly high-risk targets.

[0151] This application proposes a complete process for identifying cross-version cross-linking vulnerabilities that spans data, code, and permissions. The process connects multiple isolated issues in the software supply chain—including cross-platform compatibility, runtime communication interruptions, binary instruction out-of-order issues, resource race conditions, and permission mapping—into a unified and traceable analysis framework. This enables the systematic discovery and identification of complex cross-version vulnerabilities, especially those "cross-linking vulnerabilities" caused by the indirect interaction of multiple versions.

[0152] The various methods of the embodiments of this application have been described above. Apparatus for implementing the above methods will now be provided.

[0153] Please refer to Figure 6 This application also provides a vulnerability detection device, including:

[0154] Module 61 is used to obtain the application's compatibility data package and / or version data package;

[0155] The generation module 62 is used to read the application list corresponding to the application, distinguish all application versions under different operating environment types, associate the application versions under different operating environment types in pairs, and generate compatible association pairs.

[0156] The first processing module 63 is used to filter the compatible data packets and / or the version data packets based on each of the compatibility association pairs to obtain the corresponding data packet set;

[0157] The second processing module 64 is used to determine whether the application has vulnerabilities based on the difference in the number of data encapsulation format embeddings between the associated version number data pairs in each data packet set.

[0158] Optionally, the second processing module 64 described above includes:

[0159] The first processing submodule is used to accumulate the sum of incremental difference intensity based on the difference in the number of data encapsulation format embeddings between the associated version number data pairs in each data packet set, and to count the difference counter.

[0160] The second processing submodule is used to determine the difference intensity relationship of the application under different operating environment types by using the ratio of the sum of incremental difference intensity to the difference counter;

[0161] The third processing submodule is used to group the versions corresponding to the application based on the first preset threshold and the difference strength relationship, and to determine whether the application has vulnerabilities based on the communication anomaly information of the application.

[0162] Optionally, the third processing submodule mentioned above includes:

[0163] The first processing unit is used to divide the difference intensity relationship based on a first preset threshold to obtain a first incremental version group with a difference intensity less than the first preset threshold and a second incremental version group with a difference intensity greater than or equal to the first preset threshold.

[0164] The second processing unit is used to obtain the communication interruption frequency and the number of response data packets containing version compatibility error identifiers of the application, and to use the communication interruption frequency and the number of response data packets containing version compatibility error identifiers as communication abnormal information of the application.

[0165] The third processing unit is used to traverse the first incremental version group and the second incremental version group according to the communication anomaly information, and filter out the root cause interruption version pair and the incremental software version pair from the group.

[0166] The fourth processing unit is used to determine whether the vulnerability type of the application is a crosslink vulnerability or a single-line vulnerability based on the root cause interruption version pair and the incremental software version pair.

[0167] Optionally, the fourth processing unit described above includes:

[0168] The first processing subunit is used to extract the disordered characters in the binary files corresponding to the root cause interruption version pair and the incremental software version pair, and parse them to obtain the corresponding standard compilation instruction pairs.

[0169] The second processing subunit is used to perform race condition judgment on the standard compilation instruction pair to determine whether there is a resource race relationship. If there is a resource race relationship, the competitive dependency type corresponding to the resource race relationship is distinguished.

[0170] The third processing subunit is configured to, based on the contention dependency type, if the contention dependency type is a static contention dependency, backtrack and verify the permission mapping relationship between the standard compilation instruction pairs corresponding to the root interrupt version pair and the incremental software version pair; if the contention dependency type is a dynamic contention dependency, backtrack and verify the consistency of the compilation complementary order between the root interrupt version pair and the incremental software version pair.

[0171] The fourth processing subunit is used to, if there is an anomaly in the backtracking verification, update the corresponding matching threshold and re-execute the steps of random character extraction, standard compilation instruction pair parsing and competition condition judgment for backtracking anomalies corresponding to static competitive dependencies; and for backtracking anomalies corresponding to dynamic competitive dependencies, randomly sample versions from the two incremental version groups, extract the compilation instructions of the sampled versions, and perform competition condition judgment with the original set of standard compilation instructions.

[0172] The fifth processing subunit is used to determine the vulnerability type of the application as a cross-link vulnerability or a single-line vulnerability based on the corresponding discrimination result of the competition condition.

[0173] Optionally, the first processing subunit described above is specifically used for:

[0174] Obtain the binary files corresponding to the root cause interruption version pair and the incremental software version pair, respectively.

[0175] Locate and extract out-of-order character fragments in the binary file caused by differences in the compilation environment;

[0176] Generate the standard compilation instruction sequences corresponding to the root cause interruption version pair and the incremental software version pair, respectively;

[0177] The disordered character fragments are matched with the standard compilation instruction sequence to obtain the standard compilation instruction pairs corresponding to each disordered character fragment; wherein, the standard compilation instruction pairs corresponding to the root interruption version pair and the incremental software version pair are summarized to form two sets of standard compilation instruction pairs.

[0178] Optionally, the second processing subunit described above is specifically used for:

[0179] Extract the resource dependencies corresponding to each instruction in the two sets of standard compiler instruction pairs to form two resource dependency sets;

[0180] By comparing the resource access methods of each instruction in the two resource dependency sets, if there is a write operation that accesses the same resource, then a resource contention relationship is identified; otherwise, no resource contention relationship is identified.

[0181] If resource contention exists, the type of contention dependency corresponding to the resource contention relationship is distinguished according to the method of determining the instruction execution order; among them, the execution order is determined at compile time and the resource access state is known, which is static contention dependency, and the execution order is affected by external conditions or the program runtime state, which is dynamic contention dependency.

[0182] Optionally, the aforementioned acquisition module 61 is specifically used for:

[0183] Obtain the data exchange packets generated by communication between different versions of the same application running under different operating environment types;

[0184] The data interaction packets are filtered for version consistency to obtain incremental update data packets of the same version;

[0185] Based on the incremental update data packet, and according to the preset compatibility judgment rules and module inclusion status, the compatible data packet and / or the version data packet are obtained by classification and parsing.

[0186] The compatible data packet is a set of data interaction packets that determine the compatibility between the sender version and the receiver version after the operating environment mapping; the version data packet is a set of data interaction packets that include usage module identifiers that have not been pre-included.

[0187] It should be noted that the device in this embodiment corresponds to the method described above, and the implementation methods in each of the above embodiments are applicable to the embodiments of this device, achieving the same technical effect. The device provided in this application embodiment can implement all the method steps implemented in the above method embodiments and achieve the same technical effect. Therefore, the parts and beneficial effects that are the same as those in the method embodiments will not be described in detail here.

[0188] This application also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the various processes of the above-described vulnerability detection method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here. The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0189] This application also provides a computer program product, including computer instructions. When the computer instructions are executed by a processor, they implement the various processes of the above-described vulnerability detection method embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0190] It should be noted that, in this document, 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. Unless otherwise specified, 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 that element.

[0191] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of an application plus the necessary general-purpose hardware platform. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of an application product. The computer application product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0192] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method of vulnerability hunting, the method comprising: include: Obtain the application's compatibility data package and / or version data package; Read the application list corresponding to the application, distinguish all application versions under different operating environment types, associate the application versions under different operating environment types in pairs, and generate compatible association pairs; Based on each of the compatibility association pairs, the compatible data packets and / or the version data packets are filtered to obtain the corresponding data packet set; The existence of vulnerabilities in the application is determined based on the difference in the number of data encapsulation format embeddings between the associated version number data pairs within each data packet set.

2. The method of claim 1, wherein, Based on the difference in the number of data encapsulation format embeddings between the associated version number data pairs within each data packet set, determine whether the application has vulnerabilities, including: Based on the difference in the number of data encapsulation format embeddings between the associated version number data pairs within each data packet set, the sum of incremental difference strengths is accumulated, and a difference counter is calculated. The ratio of the sum of incremental difference intensities to the difference counter is used to determine the difference intensity relationship of the application under different operating environment types; Based on the first preset threshold and the difference strength relationship, the versions corresponding to the application are grouped, and based on the communication anomaly information of the application, it is determined whether the application has vulnerabilities.

3. The method of claim 2, wherein, Based on a first preset threshold and the relationship of difference strength, the versions corresponding to the applications are grouped, and based on the communication anomaly information of the applications, it is determined whether the applications have vulnerabilities, including: The difference intensity relationship is divided based on a first preset threshold to obtain a first incremental version group with a difference intensity less than the first preset threshold and a second incremental version group with a difference intensity greater than or equal to the first preset threshold. The frequency of communication interruptions and the number of response data packets containing version compatibility error identifiers of the application are obtained, and the frequency of communication interruptions and the number of response data packets containing version compatibility error identifiers are used as communication anomaly information of the application. Based on the communication anomaly information, traverse the first incremental version group and the second incremental version group, and filter out the root cause interruption version pair and the incremental software version pair from the group; Based on the root cause interruption version pair and the incremental software version pair, the vulnerability type of the application is determined to be either a crosslink vulnerability or a single-line vulnerability.

4. The method of claim 3, wherein, Based on the root cause interruption version pair and the incremental software version pair, the vulnerability type of the application is determined to be either a crosslink vulnerability or a single-thread vulnerability, including: Extract the disordered characters from the binary files corresponding to the root cause interruption version pair and the incremental software version pair, and parse them to obtain the corresponding standard compilation instruction pairs; The standard compilation instruction pairs are subjected to race condition judgment to determine whether there is a resource race relationship. If there is a resource race relationship, the race dependency type corresponding to the resource race relationship is distinguished. Based on the competition dependency type, if the competition dependency type is a static competition dependency, then the permission mapping relationship between the standard compilation instruction pairs corresponding to the root interrupt version pair and the incremental software version pair is backtracked and verified; if the competition dependency type is a dynamic competition dependency, then the consistency of the compilation complementary order between the root interrupt version pair and the incremental software version pair is backtracked and verified. If the backtracking verification is abnormal, for backtracking abnormalities corresponding to static competitive dependencies, the corresponding matching threshold is updated and the steps of random character extraction, standard compilation instruction pair parsing, and competition condition judgment are re-executed; for backtracking abnormalities corresponding to dynamic competitive dependencies, versions are randomly sampled from the two incremental version groups, the compilation instructions of the sampled versions are extracted, and competition condition judgment is performed with the original set of standard compilation instructions. Based on the judgment result corresponding to the competition condition, the vulnerability type of the application is determined to be either a cross-link vulnerability or a single-line vulnerability.

5. The method of claim 4, wherein, Extract the disordered characters from the binary files corresponding to the root cause interruption version pair and the incremental software version pair, and parse them to obtain the corresponding standard compilation instruction pairs, including: Obtain the binary files corresponding to the root cause interruption version pair and the incremental software version pair, respectively. Locate and extract out-of-order character fragments in the binary file caused by differences in the compilation environment; Generate the standard compilation instruction sequences corresponding to the root cause interruption version pair and the incremental software version pair, respectively; The disordered character fragments are matched with the standard compilation instruction sequence to obtain the standard compilation instruction pairs corresponding to each disordered character fragment; wherein, the standard compilation instruction pairs corresponding to the root interruption version pair and the incremental software version pair are summarized to form two sets of standard compilation instruction pairs.

6. The method of claim 4, wherein, The standard compiler instruction pairs are subjected to race condition judgment to determine whether a resource race relationship exists. If a resource race relationship exists, the race dependency type corresponding to the resource race relationship is distinguished, including: Extract the resource dependencies corresponding to each instruction in the two sets of standard compiler instruction pairs to form two resource dependency sets; By comparing the resource access methods of each instruction in the two resource dependency sets, if there is a write operation that accesses the same resource, then a resource contention relationship is identified; otherwise, no resource contention relationship is identified. If resource contention exists, the type of contention dependency corresponding to the resource contention relationship is distinguished according to the method of determining the instruction execution order; among them, the execution order is determined at compile time and the resource access state is known, which is static contention dependency, and the execution order is affected by external conditions or the program runtime state, which is dynamic contention dependency.

7. The method of claim 1, wherein, Obtain the application's compatibility data package and / or version data package, including: Obtain the data exchange packets generated by communication between different versions of the same application running under different operating environment types; The data interaction packets are filtered for version consistency to obtain incremental update data packets of the same version; Based on the incremental update data packet, and according to the preset compatibility judgment rules and module inclusion status, the compatible data packet and / or the version data packet are obtained by classification and parsing. The compatible data packet is a set of data interaction packets that determine the compatibility between the sender version and the receiver version after the operating environment mapping; the version data packet is a set of data interaction packets that include usage module identifiers that have not been pre-included.

8. A vulnerability detection device, characterized in that, include: The acquisition module is used to acquire the application's compatibility data package and / or version data package; The generation module is used to read the application list corresponding to the application, distinguish all application versions under different operating environment types, associate application versions under different operating environment types in pairs, and generate compatible association pairs. The first processing module is used to filter the compatible data packets and / or the version data packets based on each of the compatibility association pairs to obtain the corresponding data packet set; The second processing module is used to determine whether the application has vulnerabilities based on the difference in the number of data encapsulation format embeddings between the associated version number data pairs in each data packet set.

9. 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 7.

10. A computer program product, characterized in that, Includes computer instructions that, when executed by a processor, implement the steps of the method as described in any one of claims 1 to 7.

Images