# An In-Depth Survey of Bypassing Buffer Overflow Mitigation Techniques
## 5 Compiler Based Mitigation Techniques
### Step by Step Procedure of Bypassing Canary, PIE, ASLR, and NX Mitigation  
We used the technique mentioned in to bypass the most significant mitigation techniques including Canary, ASLR, PIE, and NX bit. Figure 30 shows the strategy that we have used to bypass all the mitigation including stack Canary.  
Figure 28: Stack with Canary word.  
Figure 29: Disassemble of copy_buff function.  
**Phase 1:** Figure 31 shows the vulnerable program used for exploitation having two vulnerabilities including printf function that will be used to exploit format string vulnerability for information leakage, and fgets function that is vulnerable to buffer overflow.  
First of all, the vulnerable program is compiled with all the mitigation's (NX, ASLR, Canary, PIE) enabled as shown in the Figure 32. We can check the enabled mitigation's using checksec utility. The next step is to exploit the format string vulnerability for revealing the memory locations in our vulnerable program, and for that purpose we have used a python script as shown in Figure 32), that will display format string output multiple times for information leakage also shown in the figure. The values starting with 7f such as the format string output 3 and 5 of correspond to libc addresses, which later can be used to bypass ASLR. The values found at format string output 9 can represent the canary value.  
**Phase 2:** The next step is to utilize the leaked information to get the libc offset after randomization and Canary value. Since, format string output 3 represents a libc address, it can be used to find out the libc offset, for example we run our program in gdb and passed the output 3 of format string as an input, which gives a random libc address as shown in Figure 33. The vmmap command can be used to display the memory mapping of libc for the current process, also shown in Figure 33. The libc offset is obtained by getting the difference of libc address and starting address of memory mapping of libc as shown in Figure 33. The obtained offset could be subtracted from any libc address to get the base address of libc after randomization. The next step is to calculate the canary value.  
Figure 30: Bypassing Stack Canary.  
Figure 31: Vulnerable C Code.  
When we disassemble our main() function in gdb, we can see, the canary is stored in RCX and is checked after the last fgets() is called as shown in Figure 33 (only required part of disassembly). Since, we also know that output 6 and 9 of format string might correspond to stack canary. We run our program in gdb and passed the output 9 of format string to program that returned a value. After that, we run our program with a break-point at 0x555555551f9, checked the value of RCX, and compare the result of both format string value and RCX value, thus, found the original stack canary as shown in Figure 33.  
Now, the next step is to determine our input string size to overwrite the stack canary and return address. To see after how many characters, canary should be placed, we create a pattern and pass it as input to our program in gdb. Using the RCX register's value, we can get the offset that will give us the number of A's to be filled before we overwrite the canary, and in our case, it is 24. After canary, there is rbp of 8 bytes. Since rip will be 8 bytes from rbp, we have to place 8 As before overwriting the return address.  
**Phase 3:** The final step is to place ROP gadgets in the payload along with the previously found addresses. It means in our payload, we would add system() function and pass /bin/sh as an argument via \"pop rdi; ret\" gadget. We created a script file as shown in Figure 34, combining all the work explained above to get leaked addresses as highlighted  
Figure 33: Checking libc Address and Stack Canary.  
Figure 32: Program Compilation and Information leakage.  
in the figure, and finally sending this payload to our vulnerable program. Running that python script file will spawn a shell, also shown in Figure 34.