## 5 Analysis-Time EXP Generation
### Address-Leakage Checker  
During the runtime analysis of a specific execution, the address leakage checker component checks if the execution trace constitutes address-leakage events. If so, the corresponding leakage information would be recorded in the exploitation context, providing references for exploitation technique applications when some exploitable state is reached. In practice, we monitor three types of address-leakage events, namely, explicit address leakage, implicit address leakage and forged address leakage.  
Explicit address leakage denotes the situation where the execution directly sends some address information to its output stream. This time, we record the leaked address \(addr_{\textit{leak}}\) in the corresponding context, and keep the execution continue until an exploitable vulnerability is encountered.  
Implicit address leakage refers to occasions where the above explicit leakage does not directly happen, but either the pointer of the output buffer or the origin of the output content can be controlled. Take the program snippet shown in Figure 6 for example. Given a POC input containing 1024 ''\(0\)', the execution of the target program would pass through the callage on printf at line 10. However, as we find the index variable that determines the pointer on the output content can be influenced by the POC input during symbolic execution, in such a case, we can bind address pointing to some known regions that contain sensitive address information (e.g., the global offset table [26]) on the symbolic pointer \(data+index\times 4\) to dynamically turn this implicit leakage into an explicit one.  
Forged address leakage refers to states that would normallybe terminated due to exception; however, under a certain transformation that breaches the consistency of the execution state, they can be transformed into a partial exploitable state. Take Figure 1b for example. Assume, in analysis time, we drive the target program with a POC input containing 0x100 'A's. Although this input would invoke the stack-overflow vulnerability at line 12, triggering a sensitive address write operation on EIP when returning from function \(func\) at line 15, we should not directly generate the final exploit input on the exploitable site as we have not leaked any address layout information to bypass ASLR yet. However, as the call on 'printf' at line 14 would print a string starting at an address pointing to the stack frame of the function 'func' and the string content is controllable by the external input, we can truncate the length of the string starting at buffer to 0x60 at that state, and therefore turn the original crashing stack overflow into a forged information leakage that would happen without triggering a segmentation fault. As the truncation would breach the data consistency of input length, we generate a partial exploit input that would trigger the forged information leak in the truncated context, and hope the POC-generation engine described in Section 4 generates a new POC input that would trigger some new vulnerability while absolutely triggeringthe forged leak event embodied by the partial exploit.  
Figure 6: A Demonstration Example on Implicit Leakage.