## 1 Introduction
Therefore, we need to introduce bidirectional interaction between the frontend POC-generation process with the backend exploit-generation process, enabling iterative POC generation so as to push forward the exploitation automaton step-by-step till the final state denoting the completion point. Challenge 2: Balance between address leakage forgery and exploitable state construction. Leaking an address pointing in the range of a payload-relative module is a prerequisite for vulnerability exploitation in an ASLR environment. In the real world, this leakage is usually carefully crafted through the exploitation of an otherwise crashing vulnerability. However, as current AEG solutions usually follow the 1-step exploit-generation philosophy, when they reach the vulnerability-triggering state on which an address-leakage event should be forged, they would simply focus on crafting exploitable states that can directly hijack control flow of the target program, completely ignoring the potential address-leakage artifacts. Some flexible scheduling over the candidate techniques based on the exact exploitation context is critically needed to pull AEG systems out of the dilemma. Challenge 3: Adaptable payload relocation. As they do not concerning ASLR, current AEG systems often generate exploits working in environments where the address space layout of the target process matches exactly the same with the analysis-time layout exactly. However, this is not the case for the ASLR environment, as the address space layout in runtime is completely different from the one exhibited in analysis time. An extra payload relocation step is needed to fix the gap. However, few current solutions pay attention to this issue. Our Solution: In this paper, we present ExpGen, a 2-step vulnerability exploitability evaluation system to address the above challenges. Given a binary program with a memory-corruption vulnerability running in an ASLR deployed environment, ExpGen firstly generates a partial exploit that can leak a sensitive address from the target program, then with this partial exploit in mind, performs iterative POC generation seeking to generate some STEP-1 POC inputs that can not only manifest the same address-leakage event, but also direct the target program to reach a new vulnerable state. Based on these STEP-1 POC inputs, ExpGen generates some analysis-time exploit that can leak the desired address information and successfully exploit the vulnerability in the exact analysis-timeenvironment, and then further performs runtime relocation on the analysis-time exploit. By feeding the relocated payload in the desired interaction order, ExpGen bridges the gap between the analysis-time environment and runtime environment, providing a completely automatic exploitability evaluation workflow with no need for human intervention from security experts. We have built a prototype of ExpGen based on the state-of-art fuzzer AFL++ [17] and symbolic execution engine S2E [18], and evaluate it on six test programs, 10 CTF&RHG challenges and four real-world applications running under Linux. Experimental results demonstrate that (1) ExpGen can generate partial exploit more efficiently than current test-case generation systems and (2) ExpGen can launch a dynamic exploitation session on all the 20 vulnerable programs in a completely automatic way. In summary, we make the following contributions in this paper:  
* We propose a new iterative partial-exploit sensitive POC-generation mechanism, that can generate 'advanced' POC inputs able to bring in the same leakage event the partial exploit carried out and trigger some new vulnerability, therefore providing support on incremental exploitability evaluation for vulnerabilities requiring multiple exploitation steps.