# Software Vulnerability Mining Techniques Based on Data Fusion and Reverse Engineering

Authors: Tieming Liu
Journal: Wireless Communications and Mobile Computing
 (2022)

---

## Abstract

Software vulnerability mining is an important component of network attack and defense technology. To address the problems of high leakage rate and false positive rate of existing static analysis methods, this paper proposes a static analysis vulnerability detection technique based on data fusion for source code. By parsing the analysis results of different detection methods and fusing the data, the technique can effectively reduce the false positive rate and the false positive rate. A prototype of a scalable source code static analysis tool is designed and implemented, which can be automatically optimized by user feedback. Finally, an example is given to demonstrate how to uncover buffer overflow software vulnerabilities in the helpctr program based on reverse engineering techniques. The experimental results show that the false positive and false negative rates are significantly reduced compared to individual vulnerability detection methods.


---

## Body

## 1. Introduction

With the rapid development of computer networks and communication technologies, the use of open network environments for global communication has become the trend of the times [1]. However, while networks provide a convenient way to share resources, they also pose a variety of security risks. The security risks of the network mainly come from the existence of security vulnerabilities in the software used [2].Software vulnerability mining is an important part of information security technology [3]. Depending on the object of analysis, vulnerability mining techniques can be divided into two categories: source code-based vulnerability mining techniques and target code-based vulnerability mining techniques [4]. The prerequisite for using source code-based vulnerability mining is that the source code must be available; for example, for some open source projects, through the analysis of its published source code, to find its possible vulnerabilities, Linux system vulnerability mining can be used in this way [5]. However, most commercial software, whose source code is difficult to obtain, cannot be mined from the source code point of view and can only use the target code-based vulnerability mining techniques. How to make full use of reverse engineering techniques to reduce the difficulty of analysis, so as to quickly locate possible software vulnerabilities, has become an important research direction in the field of software vulnerability mining [6].Due to the limitations of static analysis, Rice’s theorem has proved that the static analysis problem is undecidable in the worst case [7]; on the other hand, most static analysis tools are not accurate enough, and the gap between the analysis model and the actual execution of the program is large, and many tools use conservative analysis methods, using flow-insensitive or many tools use conservative analysis methods, using flow-insensitive or context-insensitive analysis methods, resulting in a high rate of missing and false positives. Although new static source code analysis tools have been introduced, such as FaultMiner [8], a tool combining data mining and static analysis, and Oink [9], a C++ code vulnerability detection tool based on type analysis, the high rate of false positives and negatives is still a hot issue in software vulnerability analysis, improvement points for such tools [10].This paper proposes a data fusion-based static source code analysis method to address the problem of high false positive and false negative rates of source code static analysis tools [11]. By integrating existing static analysis tools, parsing the analysis results and data fusion, the different output results can be verified with each other, which effectively improves the identification rate of real vulnerabilities and thus achieves better performance [12].The second part of this paper introduces the concept of reverse engineering, including the white box and black box analysis methods commonly used in reverse engineering; the third part introduces the working principle of data fusion-based static analysis of source code; the fourth part describes the design and implementation of a prototype system using the input tracking method; the fifth part is an experimental demonstration, and the sixth part is a summary of the whole paper.


## 2. Reverse Engineering-Based Research Route

The research route of software vulnerability mining technology based on reverse engineering is to first disassemble the binary code to be analyzed, to obtain the assembly code, then to slice the assembly code, i.e., to reduce the complexity of certain contextually relevant and meaningful code to converge, and finally to determine whether there are vulnerabilities by analyzing the functional modules [13–16]. Reverse engineering methods can be divided into white box and black box methods, depending on whether or not disassembly and decompilation are used to obtain the code in its high-level language representation [17].White box analysis refers to the analysis and understanding of the source code. For the binary code to be analyzed, the source code in its high-level language is obtained by decompiling and disassembling, and this source code is further analyzed in what can be considered a white box analysis. White box testing can be very effective in finding design and implementation errors in software if supported by good decompilation tools. However, white box testing has the disadvantage that the resulting code may differ from the actual source code and may therefore misrepresent vulnerabilities that do not exist [18].Black box analysis is the process of probing a program with various inputs and analyzing the results of the program run. This method requires only a running program and does not require any form of source code analysis. The test conditions are that the program is runnable, that it accepts input, and that the results can be observed. If the tester can provide input to the running program and can observe the output, then black box testing can be performed [19]. In black box testing, it is possible to provide as many malicious input vectors to the program as possible, and if the program is abnormal when tested with a particular test vector, this is a sign that a vulnerability in the program may have been found. Black box testing is less effective than white box testing in understanding the logic and behaviour of the code and requires more experience on the part of the software analyst. However, black box testing is easier to implement as it does not require the support of tools such as disassembly and decompilation [20].


## 3. Data Fusion-Based Static Analysis

Source code static detection tools with different mechanisms have different analysis tools, and the design ideas and implementation details of the same type of tool with approximately the same mechanism also differ, and the software vulnerabilities that can be found also differ. For example, different vulnerability rule bases, different heuristic strategies in the implementation of the algorithm, and different hazard levels of vulnerability definitions can all change the identification rate of software vulnerabilities. For example, the most commonly used and efficient tools (Its4, Rats, and Flawfinder) have shown that, by testing the same software packages, Flawfinder found the most vulnerabilities, but did not completely cover the part of vulnerabilities found by Rats and Its4; the number of vulnerabilities found by Rats and Its4 was not very different, but the number of vulnerabilities found by Rats and Its4 is not very different, but there are many disjoint parts. If we can make full use of the advantages of each static analysis tool and fuse the results of each tool in an appropriate way, the set of vulnerability results can verify each other and complement each other; on the one hand, the leakage rate of static analysis of source code will be reduced, and as many vulnerabilities as possible will be found; on the other hand, if the fused results can be reasonably evaluated, then the false alarm rate of vulnerabilities will also be reduced. On the other hand, if the fusion results can be reasonably evaluated, then the false alarm rate will be reduced. Based on the above ideas, this paper proposes a method for static analysis of source code based on data fusion.Proposition:(1)
A vulnerability that is identified by most tools is highly likely to be a vulnerability(2)
A vulnerability that is misreported by all tools has a relatively low probability of occurringExplanation:Givenn static analysis tools, the correct reporting rate of the ith static analysis tool is TPi (true positives), and then, the false positive rate is FPifalsepositives=1−TPi.
(1)
By∏i=1nTPi<minTPi, the probability of vulnerability being identified by n tools at the same time is reduced, which is reasonable because most of the code is nonvulnerable and the probability of the vulnerability itself is low(2)
The probability that a vulnerability will be falsely reported byn tools at the same time is ∏i=1nTPi<minTPi; if TPi<1/2, then ∏i=1nTPi<1/2n. Clearly, as n increases, the probability that vulnerability will be falsely reported by n tools at the same time decreases significantly. If the results of different static analyses are comparable, i.e., if they are transformed into a uniform intermediate format, then the probability of a vulnerability being a real vulnerability can be evaluated and predicted by defining an estimation random variable X for each vulnerability. Since vulnerabilities identified by most tools are more likely to be vulnerabilities than those identified by a few tools, the criteria for defining the estimated random variable X for each vulnerability are as follows:(1)
Increased scores for vulnerabilities identified by multiple tools simultaneously(2)
Vulnerability entries with a high risk level of their own vulnerability are scored higher(3)
Vulnerability entries with a low or infrequent risk level are given a lower score(4)
The contribution of the analysis results of different tools to the score can be adjusted according to a user-specified ratio, combined with feedback to a more appropriate ratioFor a particular vulnerability vul,si is the estimation variable of the ith tool (1<=i<=n); ri is the contribution of the ith tool to the analysis result (1<=i<=n), rsi is the actual estimation score of the ith tool (1<=i<=n). vuli=1 means that the vulnerability vul is identified by the ith tool (1<=i<=n), where it satisfies
(1)∑i=1nri=1;rsi=sivu1i=10,(2)EX=∑i=1nrsiri.The estimation variablesi maps the hazard level of the vulnerability vul entry given by the tool i to the estimation value given by the tool. This is because vulnerabilities with a higher hazard level are more likely to be vulnerabilities than those with a lower hazard level and should have a higher priority output. For example, the risk level of vulnerability entries given by Its4 is divided into three categories: high, medium, and default; if the distinction is made on a five-point scale, the mapping is fhigh=5, fmedium=3, and fdefault=1. The size of the ri value can be specified in the user interaction and can be adjusted by feedback to automatically find the best value. From the above definition, the mathematical expectation EX of the estimation variable X reflects the result of the analysis of vulnerability by n tools, i.e., the evaluation value of vulnerability after data fusion.


## 4. System Design and Implementation

Based on the above working principle, this paper implements a prototype system for source code static analysis tools (ISA for short), which has the following features:(1)
Integrating the advantages of multiple analysis tools and validating different result sets against each other to reduce false positives and missing positives(2)
Incorporating user interaction in data fusion and data output and introducing a feedback mechanism in parameter value setting, which can effectively guide the vulnerability mining process(3)
The system design and implementation adopt object-oriented design ideas and methods, with good scalability and cross-platform(4)
The output of the system can be in XML format, which is easy to describe and parse, as well as to share data. The following is the architecture design and detailed implementation of the system


### 4.1. Architecture Design of the System

The system framework design is shown in Figure1.
(1)
The source code of the program is analyzed by a static analysis tool stack to obtain the output results of the different analysis tools. The so-called static analysis tool stack is a framework that can integrate multiple analysis tools, and each analysis tool can be used independently of each other. Considering that the output of Rats, Its4, and Flawfinder can be easily compared with each other and is more commonly used, this paper first implements the comparative analysis of these three analysis tools, and new static analysis tools can be added to this stack as needed; the principle is similar(2)
The main task of output parsing is to extract valid vulnerability information from the output results by means of lexical analysis, for the specific format of the tool analysis results output, so that the subsequent data fusion module can be used. In the design of the output parsing module, an inheritance pattern is used, where a unified parent class process is used to handle some operations that may be the same for different tools and subclasses (such as Rats-pro-process and Its4-process) inherited from the parent class are used to parse the output of a specific tool to facilitate the expansion of new static analysis tools(3)
The above parsing is converted into a uniformly formatted data structure in the form of a six-tuple sequence (name of the file where the vulnerability is located, line number, risk level, type of vulnerability, function causing the error, and vulnerability risk estimate)(4)
The results of the analysis of several tools are fused with the data, following the guidelines in the second part of the principle. For example, if a tooli does not find a vulnerability entry, the estimated score of this entry in the tool is rsi=0. It is easy to calculate the estimated score of a vulnerability entry(5)
After the data has been fused, the sorting module of the corresponding vulnerability set is invoked and all vulnerabilities are ranked in descending order of estimation and a threshold value (confidence value) can be specified based on user interaction, keeping the vulnerabilities with higher estimation scores in a formatted output. An alternative format is XML format, which is easy to read and parse for vulnerabilities(6)
Compare the results of the above analysis with the actual vulnerability analysis results to find differences in the distribution of vulnerabilities, feed the information characterizing the differences to the data fusion module through the parameter training module, adjust the weight ofri, and refuse the data of the n result sets, and iterate this process until the parameter ri is trained to a suitable ratio to produce better results [21]Figure 1
ISA system architecture.


### 4.2. System Design

(1)
The whole system implementation adopts an object-oriented design approach, using object factory, monad, strategy, template, and other design patterns, with good scalability and robustness; the implementation is in C/C++ language, easy to cross-platform. Figure2 gives a partial class diagram of the system; main control is the main control class of the system process, which controls the processing of ISA; the dashed line indicates the dependencies; the main control class creates two parent classes, ResFactory class and Process class. The ResFactory class is the parent of the object factory; the three subclasses Its4-Factory, Rats-Factory, and Flaw-Factory are responsible for the creation of its corresponding objects; the Process class is the parent of the output parsing class, used to provide a uniform call interface and encapsulate the same operations(2)
The static analysis results are output in various description languages including XML format to meet the needs of different users. Figure3 shows a diagram of a vulnerability entry after data fusion with a DTD definitionFigure 2
System part class diagram.Figure 3
Schematic representation of an XML description of a vulnerability entry.


## 4.1. Architecture Design of the System

The system framework design is shown in Figure1.
(1)
The source code of the program is analyzed by a static analysis tool stack to obtain the output results of the different analysis tools. The so-called static analysis tool stack is a framework that can integrate multiple analysis tools, and each analysis tool can be used independently of each other. Considering that the output of Rats, Its4, and Flawfinder can be easily compared with each other and is more commonly used, this paper first implements the comparative analysis of these three analysis tools, and new static analysis tools can be added to this stack as needed; the principle is similar(2)
The main task of output parsing is to extract valid vulnerability information from the output results by means of lexical analysis, for the specific format of the tool analysis results output, so that the subsequent data fusion module can be used. In the design of the output parsing module, an inheritance pattern is used, where a unified parent class process is used to handle some operations that may be the same for different tools and subclasses (such as Rats-pro-process and Its4-process) inherited from the parent class are used to parse the output of a specific tool to facilitate the expansion of new static analysis tools(3)
The above parsing is converted into a uniformly formatted data structure in the form of a six-tuple sequence (name of the file where the vulnerability is located, line number, risk level, type of vulnerability, function causing the error, and vulnerability risk estimate)(4)
The results of the analysis of several tools are fused with the data, following the guidelines in the second part of the principle. For example, if a tooli does not find a vulnerability entry, the estimated score of this entry in the tool is rsi=0. It is easy to calculate the estimated score of a vulnerability entry(5)
After the data has been fused, the sorting module of the corresponding vulnerability set is invoked and all vulnerabilities are ranked in descending order of estimation and a threshold value (confidence value) can be specified based on user interaction, keeping the vulnerabilities with higher estimation scores in a formatted output. An alternative format is XML format, which is easy to read and parse for vulnerabilities(6)
Compare the results of the above analysis with the actual vulnerability analysis results to find differences in the distribution of vulnerabilities, feed the information characterizing the differences to the data fusion module through the parameter training module, adjust the weight ofri, and refuse the data of the n result sets, and iterate this process until the parameter ri is trained to a suitable ratio to produce better results [21]Figure 1
ISA system architecture.


## 4.2. System Design

(1)
The whole system implementation adopts an object-oriented design approach, using object factory, monad, strategy, template, and other design patterns, with good scalability and robustness; the implementation is in C/C++ language, easy to cross-platform. Figure2 gives a partial class diagram of the system; main control is the main control class of the system process, which controls the processing of ISA; the dashed line indicates the dependencies; the main control class creates two parent classes, ResFactory class and Process class. The ResFactory class is the parent of the object factory; the three subclasses Its4-Factory, Rats-Factory, and Flaw-Factory are responsible for the creation of its corresponding objects; the Process class is the parent of the output parsing class, used to provide a uniform call interface and encapsulate the same operations(2)
The static analysis results are output in various description languages including XML format to meet the needs of different users. Figure3 shows a diagram of a vulnerability entry after data fusion with a DTD definitionFigure 2
System part class diagram.Figure 3
Schematic representation of an XML description of a vulnerability entry.


## 5. Example Analysis

If you execute the hcp:// command in the URL bar of IE browser, the Windows XP operating system will start the Help and Support Centre application. Following the above format of gradually increasing the length of the URL input, after several tests, it can be seen that a URL string longer than 259 bytes will cause an exception to the application, at which point the helpctr.exe program will not start properly. This indicates a possible security vulnerability caused by the input point. The use of input trace testing techniques, combined with debug logging, can help locate the flawed code. The test environment was Windows XP Professional Simplified Chinese version without the Service Packet patch installed. When the program crashed, the system’s real-time debugging tool was used to record the stack calls in case of an exception, and the resulting stack record is shown in Table1.Table 1
Stack call log in case of program crash.
0006f8ac0100b4ab0006f8d80012000000000103msvert wesneal+0xle0006fae40050004f0012000000279b6400279b44HelpCtr+0xb4ab0054004b00000000000000000000000000000000x50004fAn analysis of the stack record shows that the last function called when the program crashed was wcsncat(). wcsncat() is probably what caused the error. Looking at the documentation, we can see that the semantics of wcsncat() is to add the source string provided by the user to the end of the target string, where the third parameter is the maximum number of characters that can be added. The IDA is used to disassemble helpctr.exe. Using the Import Functions window bar of the IDA, the function wcsncat() was located and the code location of the call to this import function was located based on the cross index of the function.By analyzing this subroutine, it can be seen that the subroutine first checks if the string pointed to by the first parameter pointer is an empty string; if it is, it goes to loc_100B4D1 according to the JZ instruction; if not, it executes the next instruction. If the string is not null, then we can see that the register is set to 103 h, i.e., 259 bytes, so the size of the allocated buffer is 259 bytes. The buffer overflow security vulnerability is therefore present in this program, and the previous test results verify the existence of this vulnerability.In this paper, wu-ftpd, Net-tools, and Pure-ftpd were selected for testing. These are real-world software, representative of real-world software, and are all related to network applications; a number of vulnerabilities, including buffer overflows, have been identified in this type of software and can be found in databases such as CVE (Common Vulnerability Exposure). The test environment is Pentium 1.6 G CPU, 256 M RAM, Linux (Red Hat 9.0). The tools selected for static source code inspection were the prototype system ISA and Rats, Its4, and Flawfinder. Table2 presents a comparison of the characteristics of the different source code packages (Ver represents the software version number, LOC represents the number of lines of code in the package after removing empty lines and comments, and LOE represents the number of lines with actual real vulnerabilities). Table 3 presents a comparison of the false positive rate between the different tools where the threshold of ISA is set at 0.21. Table 4 presents a comparison of the miss rate between the different tools, and Table 5 presents a comparison of the efficiency between different tools.Table 2
Characteristics of the different source packages analyzed.
ProgramVerLOCLOELOE/LOCWu-ftpd2.5.013582640.47%Net-tools1.464146501.21%Pure-ftpd1.0.17a2523013.96E−5Table 3
Comparison of false alarm rates between ISA, Rats, Its4, and Flawfinder.
ProgramISARatsIts4FlawfinderWu-ftpd76.1%93.12%94.28%90%Net-tools74.07%94.25%94.37%88.18%Pure-ftpd100%100%100%100%Table 4
Comparison of leakage rates between ISA, Rats, Its4, and Flawfinder.
ProgramISARatsIts4FlawfinderWu-ftpd28.1%39.1%39.1%29.6%Net-tools6%26%20%14%Pure-ftpd100%100%100%100%Table 5
Comparison of efficiency between ISA, Rats, Its4, and Flawfinder.
ProgramISARatsIts4FlawfinderWu-ftpd23.9%02.5%17%Net-tools25.9%01.7%18.4%Pure-ftpd0000TP represents the number of true vulnerabilities detected by the tool, NUM represents the number of output results detected by the tool,TP∗ represents the number of true vulnerabilities detected by the tool after specifying the ISA threshold, NUM∗ represents the number of output results after specifying the ISA threshold, RTP represents the number of true vulnerabilities found in the first (NUM∗ratio) bars after the tool specifies the ratio, where the miss false negative=1−TP/LOE, false positives=1−TP/NUM, for ISA, false positives=1−TP∗/NUM∗; for tool execution efficiency, for ISA, the number of vulnerabilities that can be found by scanning the output after the specified threshold is analyzed, efficiency=TP∗/NUM∗; for ISA, the number of vulnerabilities that can be found by scanning the output after the specified threshold is analyzed, efficiency=TP∗/NUM∗; for ISA, the number of vulnerabilities that can be found by scanning the output after the specified threshold is analyzed, efficiency=TP∗/NUM∗; for other tools, due to the large set of vulnerability output, there is no corresponding vulnerability priority ranking; the probability of finding vulnerabilities on a scan-by-scan basis is lower; take the ratio=0.3, efficiency=RTP/NUM∗ratio, through training and user interaction in the adjustment, ISA set the threshold value of 0.21.It is easy to see from the above data that both the ISA false positive and false positive rates have been significantly reduced, with the exception of the Pure-ftpd package, where there is only one vulnerability in the source package, which was not found by any of the three original tools, and according to the corresponding algorithm for data fusion, this vulnerability has still not been found, so both the false positive and negative rates are 100%. The comparison of productivity reflects the priority ranking of vulnerabilities, allowing users to find more real vulnerabilities in less time. This leads to the following advantages of the tool: data fusion of multiple tool result sets improves detection rates; manual interaction and feedback adjust the set thresholds, thus finding more vulnerabilities in less time and improving mining efficiency. Set appropriate thresholds to improve correctness and reduce false positives.


## 6. Conclusions

In this paper, we propose a static source code analysis method based on data fusion for vulnerability mining and design and implement a prototype source code analysis system (ISA) to achieve better performance by fusing the results of multiple static analysis tools and combining the advantages of each tool. The next step of research is to integrate more vulnerability analysis tools into this prototype system and to investigate more effective data fusion algorithms to further reduce the rate of missed and false positives.



---

*Source: 4329034-2022-04-23.xml*