## 6 Runtime-Exp Relocation
### Dynamic Exploitation with Constraint-based Relocation  
At the final stage, ExpGen synthesizes all the auxiliary information mentioned above, transferring the analysis-time exploit into a well-suited one for the running process during the exploitation session. Algorithm 1 shows the complete process.  
```
1:The full duplex channel to connect to the target process, _proc_.
2:The analysis-time exploit input, \(Exp_{analysis}\).
3:The meta data on \(Exp_{analysis}\), \(ExpMd\).
4:The IO sequence, \(IOSeq=\{IOEntry_{1},IOEntry_{2},\dots,IOEntry_{n}\}\), where \(IOEntry_{i}(1\leq i\leq n)\) is the record describing the \(i\)th IO action.
5:The leaked address descriptions, \(LADesc=\{LADesc_{1},LADesc_{2},\dots,LADesc_{n}\}\), where \(LADesc_{i}\) (\(1\leq i\leq n\)) characterizes the \(i\)th leaked address in the output stream.
6:\(smtSolver=SMTSolver()\)
7:\(contents=Exp_{analysis}\)
8:\(sendIndex=0\)
9:\(recvIndex=0\)
10:\(LAIndex=0\)
11:for each \(IOEntry\in IOSeq\)do
12:if\(IOEntry.type==READ\)then
13:\(sendIndex\_end=sendIndex+IOEntry.len\)
14:\(proc.send(contents[sendIndex:sendIndex_end])\)
15:\(sendIndex=sendIndex_end\)
16:elseif\(IOEntry.type==WRITE\)then
17:\(recvContent=proc.receive(IOEntry.len)\)
18:if\(recvIndex<=LADesc_{LAIndex}.offset\)\(AND\)\(IOEntry.len+recvIndex>=LADesc_{LAIndex}.offset+LADesc_{LAIndex}.len\)then
19:\(leakAddr=extractLeakAddr(recvContent,\)
20:\(LADesc_{LAIndex}.offset-recvIndex,\)
21:\(LADesc_{LAIndex}.length,LADesc_{LAIndex}.fmt)\)
22:\(modBase=leakAddr-LADesc_{LAIndex}.modOffset\)
23:\(analysisAddrs=ExpMd.addr\_slots[LADesc_{LAIndex}.modName]\)
24:\(actualAddrs=relocAddrs(analysisAddrs,modBase)\)
25:\(smtConstraint=rewriteConstraint(ExpMd.smtConstraint,\)
26:\(analysisAddrs,actualAddrs)\)
27:\(content=smtSolver.query(smtConstraint)\)
28:\(LAIndex=LAIndex+1\)
29:endif
30:\(recvIndex=recvIndex+IOEntry.len\)
31:endif
32:endfor
```  
**Algorithm 1** Runtime Exploitation Session with Constraint Based Payload Relocation  
Given the full duplex channel proc connected to the target process, the complete exploit \(Exp_{analysis}\) generated in analysis-time, the corresponding meta data \(ExpMd\), the IO sequence \(IOSeq\), and the leaked address descriptions \(LADesc\), the algorithm arrangesthe input/output actions in the exact order specified by _IOSeq_. When a READ action should be performed, the corresponding region in content is located and then sent to the target process through the _send_ interface of proc. When a WRITE action is on demand, that is, the target process sends back some data to us, we fetch the data through the receive interface, and then check if an address leakage exists in by referencing description \(LADescs_{LALIndex}\) of the current anticipated leak address at line 13. If it is confirmed to exist, the actually leaked address is calculated at line 14-16, on which we can obtain the corresponding load base of the module M in which the leaked address resides (line 17). This module base is then utilized to calculate the corresponding runtime addresses actualAdds for all the address values analysisAdds used in analysis-time exploit generation that resides in the same module at analysis time (line 18-19). We then derive an updated exploit constraint by substituting analysisAdds to actualAdds in ExpMd.smtConstraint (line 20-21). Through querying on this constraint, we can generate a new exploit (line 22) correctly fixing the gap for module M between analysis-time and runtime. For ongoing IO interactions, this updated exploit (line 21) would be used as source of input stream; therefore, the updated exploit can be sent to the target process, executed normally in the runtime address space-layout.