# Analyzing and Discovering Spatial Algorithm Complexity Vulnerabilities in Recursion
## 5 Evaluation
### Result and Analysis
#### 5.2.1 RQ1: Effectiveness  
In our research, due to the limitations of existing datasets and our ultimate goal of detect new algorithmic complexity vulnerabilities, we have opted to analyze real-world projects. To obtain representative results for our analysis, we primarily search for popular projects in the Maven repository and conduct in-depth analyses of these popular repositories. Our primary targets for analysis include projects such as Jettison, Ini4j, org.apache.pdfbox, etc. Jettison is a well-received Java library that facilitates the conversion between Extensible Markup Language (XML) and JavaScript Object Notation (JSON) using Streaming API for XML (StAX). Ini4j is a Java API designed for handling configuration filesin the Windows.ini format. The org.apache.pdfbox is an open-source Java tool dedicated to working with PDF documents. We ran our tool on these popular Maven projects for testing, obtaining the experimental results as shown in Table 1. The column from left to right shows the project name (Benchmark), the number of stars obtained by the project on GitHub (Stars), the number of forks (Forks), the number of other project that reference this project (Usage), the total number of classes in the corresponding JAR file (TotalClasses), the number of call paths that meet the filtering criteria (VulnerablePath), and the number of verified external-accessible paths (VerifiedPath). For example, the _hutool-json_ project has gained 27.2 k stars and 7.3 k forks on GitHub, and is used by 95 downstream projects in the Maven repository. Upon analysis, we found that _hutool-json_ contains a total of 74 classes. There are 30 paths that meet our filtering criteria, i.e., specific recursive structure, unsafe termination conditions, and unhandled error calling structure, of which 12 are externally accessible. It is worth noting that these 30 paths are all unsafe paths related to vulnerabilities, but due to some class methods being externally unreachable (i.e., non-usage methods), a total of 12 exploitable vulnerability paths have been decided. Among these 12 vulnerability exploitation paths, due to the similar principles of some vulnerabilities, only three CVE numbers were authorized by the official during the reporting process. However, in fact, these 12, and even these 30 paths are the real paths with vulnerabilities. Our effectiveness is primarily reflected in the following aspects: Firstly, we can perform detailed analysis of JAR files, extracting all classes and methods, without the need to manipulate the source code. Secondly, we are able to conduct a thorough analysis of the call chain of the JAR files, filtering out all our ACV model-related potential vulnerability paths. Additionally, due to the multifaceted constraints of our model, all identified potential vulnerabilities actually pose security issues. The only uncertainties lie in aspects such as external accessibility and similarity in the structure of the vulnerability principles. Lastly, all discovered paths are verified or officially recognized as vulnerabilities. For the comparative experiments, we compared our tool with Google's open-source fuzzing tool, _oss-fuzz_[40] (GitHub 9.4 k stars). The _oss-fuzz_ supports fuzzing Java source code to discover vulnerabilities such as crashes and memory leaks (the final effect achieved is the same as our targeted spatial ACV). As _oss-fuzz_ requires specific method as fuzzing entry and necessitates extensive time for execution, we selected the vulnerable method, i.e., XML.toJSONObject method of _org.json_, JSONObject.<init> method of _org.json_ and JSONObject.<init> method of _org.codehaus.jettison.json_ as the example entries for _oss-fuzz_ and our tool. As shown in Table 2, the column for left to right shows the entry method, the tool, the testing results, the number of generated test cases, the time consumption and the average memory consumption, respectively.