## 1 Introduction  
Finding bugs in software systems and making on-time repairs is always a critical problem in information security research communities. In the last few decades, with the great enhancement in computation power and constraint solving ability, fuzzing [1, 2] and symbolic execution [3, 4] have become two mainstream bug-finding techniques in both academy and industry, with derivative techniques including coverage guided fuzzing [5, 6], hybrid fuzzing (a composition of fuzzing and concolic execution) [7, 8] proposed and effectively applied in bug finding. With massive crashing inputs generated everyday through different kinds of vulnerability discovery systems, effective automatic vulnerability assessment becomes a must for security analysts as manual analysis is obviously expensive and impossible. Based on taint analysis, tools including lexploitable [9] and HCSIFTER [10] are proposed. Given a specific crashing input, these methods quickly lead the program execution to a crashing point, make some necessary fixes to the corrupted state (e.g., recovering the data corrupted by heap overflow), and then walk further along the state, and report the vulnerability that is exploitable if a taint-based exploitable pattern could be matched. However, as they manifest exploitability without generating exploit input, false positives exist. Since the Cyber Grand Challenge event [11] DARPA held in 2016, automatic exploit generation(AEG) has become a hot research topic. Solutions including CRAX [12], REX [13], Mayhem [14], are proposed, to discover vulnerabilities and automatically generate exploits when possible, for source code and binary respectively. In general, these methods often first analyze vulnerabilities in detail along the trace of the crashing input, check out the vulnerability triggering state, then explore further from the vulnerability triggering state to search for program states that are deemed exploitable. Once a exploitable state is derived, these methods collect path-reachability constraints, vulnerability-triggering constraints and exploit-construction constraints separately through symbolic execution, then solve the conjunction of these constraints using SMT (satisfiability modulo theories) [15] solvers, with exploit input finally generated. However, currently, most AEG solutions can be applied only in exploit generation for vulnerabilities requiring limited exploitation steps in an environment where the Address Space Layout Randomization(abbr. ASLR) [16] vulnerability mitigation mechanism is not deployed. As for vulnerabilities in an ASLR condition, human analysts usually need to leak some important address information from the target process first, then adjust the payload content referencing the leaked address, and finally send the relocated data to the target process to complete the exploitation session. We find that to make this process automatic without human intervention, the following three key challenges should be addressed, which are commonly ignored by current solutions. Challenge 1: Iterative proof-of-concept generation. Current AEG systems usually first generate some proof-of-concept (abbr. POC) input, then use it to drive the automatic exploit-generation engine to begin its reasoning process. From a systematic perspective, the POC input-generation process and the exploitable state-deduction process are completely separated. This design fits for the 1-step vulnerability exploitation process, where the exploitable state is already implied within the trace of the provided POC input. However, as demonstrated later, exploitability evaluation for vulnerable binary programs running in an ASLR environment often consists of multiple exploitable state-deduction steps, each of which requires a new POC built on capabilities accumulated from the previous exploitation steps.