# SGXDump: A Repeatable Code-Reuse Attack for Extracting SGX Enclave Memory
## 5 Attack Design
### SGXDump ROP Payload Structure  
This subsection describes the SGXDump ROP payload in detail. Since the SGXDump consists of a relatively large amount of code compared to normal ROP payloads, we grouped its code into four steps and depicted the overall flow in Algorithm 1. After giving a short summary of each step, we provide in-depth explanations. ```
1:Registers\(\leftarrow\emptyset\)
2:while true do
3: Calculate sync address (Step 1)
4:if\(RSP\) does not have the next gadget address then
5:continue
6:end
7: Get secret data (Step 2)
8: Shift and access probe array (Step 3)
9: Loop (Step 4)
10:end
```  
**Algorithm 1** Flow of ROP payload. * **Step 1. Calculating sync address. ** The ROP payload initializes several registers to avoid unpredictable behaviors. After reading the value at the sync address, SGXDump uses the value as a sign to access the next data or to jump back to check the sync address for busy waiting. * **Step 2. Getting protected data. ** At this stage, the ROP retrieves two values from the index address and the target address and adds the two values to calculate the next address in enclave memory. Then, the ROP reads one byte from the address and stores it in a register temporarily. * **Step 3. Shifting protected data and accessing probe array. ** The ROP payload left-shifts the data 12 times, multiplying by 4096, and uses the resulting value as an index to access the probe array. * **Step 4. Looping. ** Before looping back to Step 1, the ROP payload increments the content at the index address and writes an offset value at the sync address to make Step 1 perform a busy waiting. A detailed description of each step is given in the following. **Step 1. Initializing and Calculating address. ** The attacker initializes the registers to be used for the ROP payload to 0. Please note that Line 1 in Listing 1 is not a single instruction, but a series of gadget addresses, each of which is a register reset instruction followed by a ret instruction. Next, the attacker loads the address of the sync to reg1 since the pop reg1 instruction takes the top of the stack (currently, _sync_address_) and stores it to reg1; an example of the ROP payload is shown in Figure 4. It is worth mentioning that the actual content in Line 2 of the ROP payload is not an instruction but a gadget address whose instruction is pop reg1 followed by a ret instruction, as in Figure 4a. We chose this way for better understanding and convenience. Thus, to construct a real SGXDump ROP payload, all instructions in the following Figures and Lists will be substituted with their corresponding gadgets' addresses. In Figure 4a, executing the ret instruction makes the control flow return to the address that is loaded in the rsp register. The rsp register has the next gadget address. After returning, the next gadget (pop reg1) is executed as shown in Figure 4b. After executing pop reg1, the address of the sync is loaded in reg1, as shown in Figure 4c. Then, Line 4 in Listing 1 loads the sync data to reg1. At first, the sync data is set to zero, so rsp register does not change after subtracting reg1. Since rsp register points to the current stack top, the succeeding ret instruction in the gadget makes the control flow go to Line 1 in Listing 2. If reg1 is not zero, sub rsp, reg1 would make the control flow jump back to somewhere in the stack. In our attack, we deliberately select this offset value ofreg1 to make the address jump to Line 2 in Listing 1, completing a busy waiting loop that is checking the content of the sync address. When the PAM module resets the sync data to zero, this busy waiting loop is broken and the control moves forward to Step 2. ```
popreg1 sync_address movreg1,qwordptr[reg1] subrsp,reg1
```  
**Step 2. Obtaining protected data. **SGXDump first moves _index_address_ to reg2 as shown by Line 1 and Line 2 in Listing 2. Then, the attacker loads the data from _index_address_ and writes it to reg2 (Line 3 in Listing 2). We use this data as an index from the base address to point to a location in the enclave memory to leak next.