## 2 Motivation Example
### The Vulnerability and Exploitation Process  
As for the example program demonstrated in Figure 1a, we compile it with options PIE [19] and NX [20] enabled and run it under Linux-i386 platform with ASLR option turned on. For simplification, we assume the _stack protector_[21] option is turned off during compilation. We can see a function containing some backdoor functionality exists in line 1-3. For brevity we assume in analysis-time the load base of the compiled image being 0x55569000, and the backdoor resides at offset 0x181 in the compiled image.  
We can also see, in line 12, there exists a call to posix-API function read, which would fetch at most 0x100 bytes from the standard input channel to the local array pointed by the buffer, whose size is only 0x60, resulting in a potential stack-overflow vulnerability. From the stack layout demonstrated in Figure 1b, we can see that, when the program receives more than 0x60 bytes, the saved EBP or, what is more important, the saved EIP, would be overwritten, therefore triggering a segmentation fault when the called function func returns. We temporarily comment out line 13, which will be discussed later in Section 2.2.2.  
The manual exploitation process of the example program is demonstrated in Figure 1c, consisting of the following phases.  
1. Address-leakage exploit generation. We craft an input \(S_{0}\) that would take up precisely 0x60 none-zero bytes. When fed to the target program, this input would not overflow the local variable buffer in func's stack frame, but can cause the call on printf at line 14 to leak extra data on the stack including the saved EBP and the saved EIP(as the EBP value usually consists of four none-zero bytes under 32 bit systems at runtime). Therefore we can obtain a leaked address of the main executable which is the return address of the callage to func in main. \(S_{0}\) would be the first data sent to the target program during the attack session.  
2. Control-flow hijack exploit generation. We generate an input \(S_{1}\) that can trigger function backdoor, which would not be invoked under normal conditions. \(S_{1}\) is composed of 0x64 none-zero bytes (note, here we pad saved EBP with 4 bytes) trailed by 0x55569181, which is backdoor's address at analysis time. Thus, when the control flow returns from func to main, we can hijack the control flow onto backdoor and obtain a shell from it.  
3. Exploit synthesis. As we have got two exploits, separately \(S_{0}\) capable of leaking a runtime address in the main executable and \(S_{1}\) capable of control-flow redirection onto backdoor in the main executable at analysis time, we now synthesize the two crafted inputs into a complete one in the following dynamic exploitation session.  
When the target program is launched, we feed it with \(S_{0}\) through the standard input channel first, and fetch the leaked runtime address \(A_{runtime}\) by monitoring the byte stream from the standard output channel. With the corresponding analysis-time address \(A_{analysis}\) in mind, we replace the analysis-time specific value 0x55569181 in \(S_{1}\) with \(A_{runtime}\)-\(A_{analysis}+0x5569181\), obtaining a new input block \(S^{\prime}_{1}\) where the target program-address-space related fields are all'relocated' to the runtime environment. Lastly, we send \(S^{\prime}_{1}\) to the target process with the desired shell successfully obtained afterwards.