A method and apparatus for classifying crash samples based on core behaviors extracted from program crash states.

Abstract

This invention discloses a crash sample classification method and apparatus based on the extraction of core behaviors of program crash states. First, the original input file is byte-type identified, marking behavioral bytes, control bytes, and immutable bytes. Then, fuzzing technology is used to mutate the corresponding bytes to explore the complete behavior of the target defect, improving identifiability. Next, the POC execution trajectory is adjusted under constraints, eliminating redundant paths and extracting the simplified execution path that triggers the crash. Finally, the complete behavior and simplified execution trajectory are used to construct a program crash state representing defect characteristics. Execution time information of the program crash state is extracted and a feature vector is generated. A vector similarity comparison algorithm is used to distinguish crash samples triggering different vulnerabilities. This invention uses fuzzing technology to extract the program crash state of crash samples with fine granularity and extracts the corresponding execution time information for crash sample classification, enabling accurate differentiation of crash samples.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to a method and apparatus for classifying crash samples based on the extraction of core behaviors of program crash states. Background Technology

[0002] Software has become an indispensable part of our daily lives, encompassing many aspects. The increasing variety of needs has led to a surge in the size and complexity of software, inevitably resulting in a rise in the number and types of software failures. Advances in automated vulnerability discovery technology have made software failure detection a fully automated process. However, the presence of numerous duplicate crash reports consumes a significant amount of time and effort for software maintenance personnel. Accurate crash sample classification remains a challenging task and a current research hotspot.

[0003] Existing crash sample classification techniques can be broadly categorized into four types: crash point-based crash sample classification, coverage-based crash sample classification, stack hash-based crash sample classification, and patch comparison-based crash sample classification. The complexity of software code manifests as the diversity of program states, which is further reflected in the diversity of crash states. This causes many vulnerabilities with the same root cause to exhibit different crash states, reducing the accuracy of existing crash clustering techniques and making it impossible to accurately distinguish samples with the same root cause but not unique crash states.

[0004] Other methods generate CFG graphs from the execution trajectory of a program and use graph similarity comparisons for crash clustering. Such techniques currently only use the minimum coverage algorithm as a guide to generate the program execution trajectory. However, using the shortest execution path as a guide will indiscriminately mutate the original POC (Proof of Confirmation) bytes, which may introduce new vulnerabilities and cause confusion. Furthermore, graph clustering algorithms will treat intra-class differences as inter-class differences when processing a single vulnerability, resulting in inaccurate statistical results. Summary of the Invention

[0005] This invention addresses the problem that existing crash sample classification techniques are not accurate enough in feature extraction, resulting in a high false positive rate. It proposes a crash sample classification method and device based on the extraction of core behaviors of program crash state. The method uses fuzzy testing technology to extract the program crash state of crash samples in a fine-grained manner and extracts the corresponding execution time information for crash sample classification, which can achieve the purpose of accurately distinguishing crash samples.

[0006] To achieve the above objectives, the present invention adopts the following technical solution:

[0007] This invention proposes a crash sample classification method based on the extraction of core behaviors in program crash states, including:

[0008] Step 1: Identify the byte type of the original input file and mark it as a behavior byte, control byte, and immutable byte;

[0009] Step 2: Use fuzz testing to mutate the corresponding type of bytes to explore the complete behavior of the target defect;

[0010] Step 3: Adjust the execution path of the vulnerability batch verification program (POC) under constraints, remove redundant paths, and extract the simplified execution path that triggers the crash;

[0011] Step 4: Construct program crash states representing defect characteristics using complete behavior and simplified execution trajectories, extract execution time information when the program crash state is triggered, generate feature vectors based on this information and perform similarity comparisons, and classify crash samples based on the comparison results.

[0012] Traditional address detectors terminate program execution upon encountering the first error, limiting opportunities to delve into the behavioral differences of vulnerabilities and causing different vulnerabilities to exhibit the same crash state. This patent delves into the complete behavior of defects, improving the distinguishability of crash samples triggering the target vulnerability from those of other vulnerabilities.

[0013] The original POC generates a large number of execution paths when executed in the program. Among them, the program paths that must be executed without triggering defects are called redundant paths. After the complete behavior exploration phase is completed, the execution paths of the seed are adjusted to remove redundant paths and obtain the simplified execution paths that must be executed to trigger defects.

[0014] Further, step 2 includes:

[0015] By comprehensively analyzing the likelihood and time cost of discovering new behaviors, seeds are assigned priority.

[0016] Furthermore, the time cost is calculated as follows:

[0017]

[0018] Where A i T represents the number of mutations required for a seed to reach its current stage. con It is the product of the average time α of each round of fuzzy testing and the number of mutations of the seed from state i to state n.

[0019] Furthermore, the seed priority is calculated as follows:

[0020]

[0021] Among them, B(C) j The `seed` property is used to determine whether newly discovered program behavior is derived from the behavior bytes C in the current `seed`. j The mutation is derived from N, where N is the total number of bytes in the seed. wei The seed priority is represented by k, which is a coefficient used to ensure that the equation is always greater than 0.

[0022] Further, step 3 includes:

[0023] Using the seed set after the complete behavior exploration as input, the control bytes in the seed set are mutated, and the execution time information of the mutated seed is recorded. If the seed is inconsistent with the target defect crash type or crash location, it is discarded. Then, the seed energy is calculated based on the execution time information. Seeds with fewer edges covered during execution or whose edges are executed fewer times during execution are given higher energy. Redundant paths are removed while keeping the program crash output unchanged.

[0024] Furthermore, in step 4, the execution information includes defect integrity behavior, program execution characteristics, and program sensitivity characteristics. The defect integrity behavior includes crash type, access type, and maximum number of accessible bytes.

[0025] Furthermore, in step 4, the similarity is calculated using cosine similarity.

[0026] Another aspect of the present invention proposes a crash sample classification device based on the extraction of core behaviors of program crash states, comprising:

[0027] The byte type identification module is used to identify the byte type of the original input file, marking behavioral bytes, control bytes, and immutable bytes;

[0028] The complete behavior exploration module is used to use fuzz testing techniques to mutate bytes of the corresponding type and explore the complete behavior of the target defect.

[0029] The execution trajectory adjustment module is used to adjust the execution trajectory of the vulnerability batch verification program under restricted conditions, remove redundant trajectories, and extract the simplified execution trajectory that triggers the crash.

[0030] The crash sample classification module is used to construct program crash states that represent defect features using complete behavior and simplified execution trajectories, extract execution time information when the program crash state is triggered, generate feature vectors based on this information and perform similarity comparisons, and classify crash samples based on the comparison results.

[0031] Compared with the prior art, the present invention has the following beneficial effects:

[0032] This invention first identifies the byte type of different crash samples, and then explores their complete program behavior and simplified execution trajectory based on the identification results, thereby generating corresponding program crash states. Next, it extracts the execution time information when the crash sample triggers the corresponding program crash state, and generates feature vectors based on this information for similarity comparison. This invention distinguishes the differences between program crash states caused by different vulnerabilities in a fine-grained manner, greatly improving the accuracy of crash sample differentiation. Attached Figure Description

[0033] Figure 1 This is a flowchart illustrating a crash sample classification method based on the extraction of core behaviors in a program crash state, according to an embodiment of the present invention.

[0034] Figure 2 This is an example diagram illustrating information extraction during the execution of an embodiment of the present invention;

[0035] Figure 3 This is a schematic diagram of a crash sample classification device based on the extraction of core behaviors of program crash state according to an embodiment of the present invention. Detailed Implementation

[0036] The present invention will be further explained below with reference to the accompanying drawings and specific embodiments:

[0037] A crash sample classification method based on the extraction of core behaviors of program crash states is proposed. This method adjusts the original input to extract the program crash state of the target vulnerability, and performs fine-grained classification of crash samples that trigger different vulnerabilities. The method flow is as follows: Figure 1 As shown, it mainly consists of four parts: byte type identification, complete behavior exploration, execution trajectory adjustment, and crash sample classification. Specifically, it first identifies the types of different bytes in the original input and assigns corresponding type labels to the bytes, specifically marking them as behavioral bytes, control bytes, and immutable bytes; then, it mutates the corresponding types of bytes to explore the complete behavior of the target defect in order to extract unique features and improve identifiability; under constraints, it adjusts the original execution path to obtain the simplified path that must be executed to trigger the defect in order to extract common features; finally, it uses the complete behavior and simplified execution trajectory to construct a program crash state representing the defect characteristics, extracts the execution time information when the program crash state is triggered, generates feature vectors based on this and performs similarity comparison, and classifies crash samples based on the comparison results.

[0038] 1. Complete Behavioral Exploration

[0039] During fuzzing, a large number of seed sequences are generated. To improve exploration efficiency, it is necessary to prioritize the seeds and select and mutate those seeds that are more likely to discover new program behaviors. As one possible implementation, this statement assigns seed priorities by comprehensively analyzing the probability of discovering new behaviors and the time cost.

[0040]

[0041] The specific calculation method for time cost is shown in formula (1), A i T represents the number of mutations required for a seed to reach its current stage. con The average time α per round of fuzzing testing is the product of the number of mutations of the seed from state i to state n. Newly generated seeds and seeds with low time consumption should be given higher priority because they are more likely to produce new program behaviors and have higher exploration efficiency.

[0042]

[0043] The seed priority calculation method is shown in formula (2), B(C j The `seed` function primarily determines whether newly discovered program behavior is derived from the behavior bytes C in the current `seed`. j The resulting mutation, N, represents the total number of bytes representing the rows in the seed. wei Representing seed priority, it is calculated by subtracting the time overhead from the number of bytes of behavior related to the new program behavior in the current seed, where the coefficient k is used to ensure the equation is always greater than 0. During the exploration phase, fuzzing only retains seeds that trigger new program behaviors and proceeds to the next round of exploration. Before the first new program behavior is discovered, B(C) represents the seed priority. j The seed is always set to 1, meaning that more recently generated seeds are given higher priority. The full behavior of crash samples is explored by assigning higher energy to seeds that are more likely to trigger new behaviors.

[0044] 2. Execution trajectory adjustment

[0045] After the complete behavior detection phase, only the control bytes in the original input can be changed; all other byte types are fixed. Therefore, this section only mutates the control bytes to adjust the execution trajectory that triggers the defect under constraints.

[0046] This section uses fuzzing to mutate the control bytes in the seed. To improve the efficiency of exploring the program's state space, the deterministic mutation process is skipped in the mutation phase, and only the mutation operators in the Havoc and Splice phases are used to mutate the control bytes. To remove redundant paths, the seed priority strategy needs to be adjusted. The specific exploration process is shown in Algorithm 1:

[0047]

[0048]

[0049] The initial input to this algorithm is a seed set whose complete behavior has been explored. Then, the control bytes of these seeds are mutated, and the execution (time) information of the mutated seeds is recorded. Seeds that do not match the target defect's crash type or location are discarded. Subsequently, the seed energy is calculated based on the execution time information. This algorithm uses the same strategy as AFL to statistically analyze program coverage information, but the energy assignment rules differ. Traditional AFL aims to maximize program coverage, assigning high energy to seeds with more execution coverage edges. This algorithm, to simplify the execution trajectory, assigns higher energy to seeds with fewer execution coverage edges or whose edges are executed fewer times. The goal is to remove redundant paths in the execution trajectory while maintaining the program crash output unchanged.

[0050] 3. Collapse Sample Classification

[0051] This section presents statistics based on the execution time information extracted from the program crash state in Sections 1 and 2. Figure 2 The image displays some of the extracted feature information, including complete defect behavior and program execution characteristics, as well as program sensitivity characteristics, such as crash type, access type, and maximum number of accessible bytes (for overflow-type defects). This information will be recorded and converted into a set of numerical features to generate... Figure 2 The feature vectors shown are used for the subsequent vector similarity comparison operation.

[0052] To distinguish the differences between two collapse samples, it is first necessary to compare the similarity of the generated feature vectors. Since the length of the feature vectors is fixed, in order to balance accuracy and efficiency, as an implementation method, this invention chooses to use cosine similarity for vector similarity comparison. Suppose there are collapse states A and B, and the corresponding generated feature vectors are Va and Vb, then the similarity calculation of the vectors is as shown in formula (3):

[0053]

[0054] By comparing similarity using formula (3), the crash samples can be accurately classified.

[0055] Based on the above embodiments, such as Figure 3 As shown, the present invention also proposes a crash sample classification device based on the extraction of core behaviors of program crash states, comprising:

[0056] The byte type identification module is used to identify the byte type of the original input file, marking behavioral bytes, control bytes, and immutable bytes;

[0057] The complete behavior exploration module is used to use fuzz testing techniques to mutate bytes of the corresponding type and explore the complete behavior of the target defect.

[0058] The execution trajectory adjustment module is used to adjust the execution trajectory of the vulnerability batch verification program under restricted conditions, remove redundant trajectories, and extract the simplified execution trajectory that triggers the crash.

[0059] The crash sample classification module is used to construct program crash states that represent defect features using complete behavior and simplified execution trajectories, extract execution time information when the program crash state is triggered, generate feature vectors based on this information and perform similarity comparisons, and classify crash samples based on the comparison results.

[0060] In summary, this invention first identifies the byte type of different crash samples, and then explores their complete program behavior and simplified execution trajectory based on the identification results, thereby generating the corresponding program crash state. Next, it extracts the execution time information when the crash sample triggers the corresponding program crash state, and generates feature vectors based on this information for similarity comparison. This invention distinguishes the differences between program crash states caused by different vulnerabilities in a fine-grained manner, greatly improving the accuracy of crash sample differentiation.

[0061] The above description is only a preferred embodiment of the present invention. It should be noted that those skilled in the art can make several improvements and modifications without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for classifying a crash sample based on core behavior extraction of a program crash state, characterized by, The method comprises the following steps: Step 1: byte type identification is performed on an original input file, and behavior bytes, control bytes and immutable bytes are marked; Step 2: the corresponding type of bytes is mutated by using a fuzzy testing technology, and the complete behavior of a target defect is explored; Step 3: the execution track of a vulnerability batch verification program is adjusted in a path under a limiting condition, redundant tracks are deleted, and a simplified execution track triggering a crash is extracted; Step 4: a program crash state representing a defect feature is constructed by using the complete behavior and the simplified execution track, execution time information when the program crash state is triggered is extracted, a feature vector is generated according to the execution time information, similarity comparison is performed, and crash samples are classified according to a comparison result. The step 2 comprises the following steps: a priority of the seed is given by comprehensively analyzing a possibility of a new behavior being discovered and time consumption; the time consumption is calculated in the following manner: wherein denotes the number of mutations required by the seed mutation to the current stage, is the average time spent per round of fuzzing is the product of the number of mutations of the seed from state i to state n. the priority of the seed is calculated in the following manner: wherein for determining whether a newly discovered program behavior is derived from a current behavior byte in the seed is mutated, is the total number of behavior bytes in the seed, represents the priority of the seed, is a coefficient for ensuring that the equation is always greater than 0.

2. The crash sample classification method based on program crash state core behavior extraction according to claim 1, characterized in that, The step 3 comprises the following steps: a set of seeds whose complete behaviors are explored is taken as input, control bytes in the set of seeds are mutated, execution time information of the mutated seeds is recorded, and the seeds are discarded if the seeds are inconsistent with a target defect crash type or a crash position; subsequently, seed energy is calculated according to the execution time information, and a seed with less execution time coverage edge number or a seed with less execution time edge execution times is given a higher energy, and redundant paths are removed under the premise that a program crash output is unchanged.

3. The crash sample classification method based on program crash state core behavior extraction according to claim 1, characterized in that, In the step 4, the execution time information comprises a defect complete behavior, program execution features and program sensitive features, and the defect complete behavior comprises a crash type, an access type and a maximum number of accessible bytes.

4. The crash sample classification method based on program crash state core behavior extraction according to claim 1, characterized in that, In the step 4, the similarity is calculated by using cosine similarity.

5. An apparatus for classifying a crash sample based on core behavior extraction of program crash states, the apparatus comprising: a crash sample classification module configured to: receive a crash sample; extract core behavior from the crash sample; and classify the crash sample based on the extracted core behavior. The method comprises the following steps: a byte type identification module is configured to perform byte type identification on an original input file, and behavior bytes, control bytes and immutable bytes are marked; a complete behavior exploration module is configured to mutate the corresponding type of bytes by using a fuzzy testing technology, and the complete behavior of a target defect is explored; an execution track adjustment module is configured to adjust a path of an execution track of a vulnerability batch verification program under a limiting condition, delete redundant tracks, and extract a simplified execution track triggering a crash; a crash sample classification module is configured to construct a program crash state representing a defect feature by using the complete behavior and the simplified execution track, extract execution time information when the program crash state is triggered, generate a feature vector according to the execution time information, perform similarity comparison, and classify crash samples according to a comparison result. In the complete behavior exploration module: a priority of the seed is given by comprehensively analyzing a possibility of a new behavior being discovered and time consumption; the time consumption is calculated in the following manner: wherein denotes the number of mutations required for the seed mutation to the current stage, is the average time spent per round of fuzzing is the product of the number of mutations of the seed from state i to state n; the priority of the seed is calculated in the following manner: wherein for determining whether a newly discovered program behavior is derived from a current behavior byte in the seed as varied, is the total number of behavior bytes in the seed, represents the priority of the seed, is a coefficient for ensuring the equation is always greater than 0.

Images