## 7 Evaluation and Discussion
### Case Study
#### 7.3.1 Security of Tamper-Proofing Instruction  
As described in Section 5, we organized our Tamper-Proofing Instruction into a ring. Comparing with guards net, TPI-Ring reduced the space overhead brought by complex network theoretically. However, TPI Handlers in TPI-ring did not lower the self-security of TPI Handlers. We can also see from Figure 4 that every TPI Handler is crossed with each other. In other words, there are at least three TPI Handlers protecting one address segment when the protected program is running. Standing by the adversary's side, when he tries to break the TPI-Ring, he would not get what he wants unless he can remove all the TPI Handlers at one time. In order to see the TPI-Ring clearly, we did some modification to re-organize and centralize the whole function TPI's three handlers together. With some reverse-engineering experiences, we found three sets of TPIs that are deployed in the virtual instructions (see Table 4). As described in Section 7.1, we set the length of TPI to 16 bytes. Based on the idea of cross protection, the start addresses and the end addresses of the three sets TPI are 0043E2E4-0043E2F4, 00E3E2 EC-0043E2 FC, and 0043E2F4-0043E304. We employed a simple checksum algorithm and added up the data of the protection range with four bytes length together for demonstration. During program execution, it will loop to re-compute a checksum1 from the start address to the end address. We assume that we choose the second set of TPI to test the functionality. Firstly, TPI_a will decrypt out a checksum (1 BEE37B2). Then, TPI_b and TPI_c will find the start address (00E3E2 EC) and the end address (0043E2 FC). Figure 10 is a part of the original TPI Handler. Here is our starting point comparing the normal checksum algorithm. The value of a register will be frequently invoked during program execution. We did not just simply compare the pre_checksum with the checksum re-calculated during the program execution. We subtract the pre_checksum from the value of a register (EBP), with loop accumulating to restore the value of EBP (see Figure 11). If the value of EBP is not changed, there is no tampering occurring. Otherwise, the program will be crashed when it comes to invoke EBP. \begin{table}
\begin{tabular}{c c c} \hline \hline
0043E2E4 & AD 33 C3 05 & DB 04 20 5F \\ \hline
0043E2 EC & 2D 23 6E A0 & 6F 2B D8 66 \\ \hline
0043E2F4 & 8B 14 24 52 & 8B D4 83 C2 \\ \hline
0043E2 FC & 04 83 C2 02 & 87 14 24 8B \\ \hline \hline \end{tabular}
\end{table} 
Table 4: TPI protected area. Figure 10: Part of the original TPI handler. Theoretically, if we modify some data within the second TPI's protection range, we believe that both the three TPIs and the whole TPI-ring can be aware of the tampering behavior. We invite a number of students to perform a practical reverse analysis of VM protection and evaluate the security of _VMGuards_ by comparing the difficulty of extracting key data and structure. These students are computer-related majors and have research experience in software security. They play the role of an attacker and target the following three points, then perform reverse analysis on _VMGuards_ and Normal VM protection and compare the results. * Target 1: Find the entrance to the virtual interpreter through analysis and debugging. * Target 2: Through analysis and debugging, locate the Dispatcher and analyze its structure and function. * Target 3: Modify the structure of the Dispatcher and output the Handler's scheduling sequence. The setting of these targets is mainly based on the classical VM reverse analysis method, which first locates the key data and structures of VM interpreter, and then tracks and fetches the execution sequence of the Handler, finally extracting the target code through optimization and simplification. The experimental results show that most participants are able to complete target 1 in the face of _VMGuards_ and Normal VM protection.