###### Abstract
Therefore, it is the AEG system's duty to forge a new canary leaking event from scratch, establishing the first step towards complete exploitation of StackGuard-protected programs. Challenge 2: sanity check bypassing input generationObtainment of a canary leaking input is not the termination. AEG system should explore the path space alongside this input to further discover some exploitable state, only on which can we derive a complete exploit input. However, as for most current test case generation techniques including fuzzing [21; 22; 23], symbolic execution [24; 25], hybrid fuzzing [26; 27], etc., the sanity check performed by StackGuard would definitely block exploitable state from being discovered as the stack structure is generally smashed. A sanity check bypassing input generation scheme should be proposed to help the AEG system tackle the issue in an effective way. Challenge 3: dynamic canary relocationCurrent AEG systems often generate exploits under the assumption that the analysis environment and the runtime environment match exactly the same. However, this is not the case for StackGuard-protected programs, as the canary value it adopted differs between each bootstrap of the environment. It is necessary to equip an extra canary relocation device to current AEG systems to fix the critical environmental gap. Our SolutionWe present CanaryExp, a canary-sensitive automatic vulnerability exploitability evaluation system to address the above challenges. Given a binary program with some memory corruption vulnerability and a POC input that can trigger some vulnerability but cannot hijack the control flow due to failure on canary checking performed by StackGuard, CanaryExp firstly monitors the execution of the POC input, generating input samples that can leak the desired canary at runtime. Based on this canary leaking input, it then generates input samples that can not only leak the canary, but also trigger some new vulnerability afterwards. We define these input samples as incremental proof of concept (abbr. incremental POC) throughout this paper. The incremental POC is then utilized by an exploitation technique applied generating exploit input that fits the analysis time environment. An extra canary relocation process is deployed at last, making the analysis time exploit adaptable to the runtime environment, providing a completely automatic exploitability evaluation workflow for security analysts. We have constructed a prototype system of CanaryExp based on the open source binary analysis platform angr [28], coverage guided fuzzing engine AFL++ [29] and whole-system symbolic executor S2E [30], and evaluated it on six test programs, eight CTF challenges and four real-world applications. The results of experiments show that (1) CanaryExp can generate canary leaking input and incremental POC able to both leak the canary and trigger some vulnerability more efficiently than current test case generation systems, and (2) CanaryExp can automatically and effectively evaluate the exploitability of the desired vulnerabilities existing in the 18 vulnerable programs that are protected by StackGuard. The main contributions of this paper are listed below:  
* We propose a novel canary leakage forge method. By performing output buffer analysis and canary recognization through dynamic state monitoring alongside the execution of a POC input, the overflowed canary in the output buffer is recovered with a canary leaking execution state derived on which canary leaking input can be automatically calculated. * We propose a canary leaking analysis time exploit generation method. By exploring state space alongside test cases that are able to leak the desired canary and disabling StackGuard's sanity check during exploitable state derivation, the analysis time exploit is generated providing a data template for later automatic construction of exploitability evaluation scheme. * We propose a dynamic canary-relocation-based exploitability evaluation mechanism.