This exercise is about creating an attack based on buffer overflow (software vulnerability) in a program on your Linux system. The buffer overflow can be done in the vuln.c code (from the link below) or any code that uses unsafe functions for reading or writing variables. Rely on the techniques developed in the link:
https://github.com/kevinkong91/buffer-overflow-exploit/tree/master

The buffer overflow should overwrite a variable in the program and eventually create in a bash shell. This will be done by changing the value of the program counter register in memory called Return Instruction Pointer (RIP in 64-bit, EIP in 32-bit).

For this purpose, you need to select or create suitable shellcode (e.g., from https://www.exploit-db.com or other site) which you need to check first that it runs on your system. The shellcode must be surrounded (above and below) by no-operations (nop sled region) and the RIP (or EIP respectively) pointer must point somewhere in the middle of the first nop-sled region to maximize the attack's chances of success.

Note that you may need several trials to successfully overwrite the RIP and create the shell. 

Additional questions:
1) Does the buffer overflow method you developed always lead to a shell?
2) Under which conditions your shell can become a rootkit?
3) Why it is preferable to do this exercise within a Linux VM instead of a real system?
4) What is the extra cost to make the program safe by changing the C function? Can you compare the cost of unsafe and equivalent safe functions? You can measure execution times using the clock_gettime() function.
5) Can the same attack be performed online? Build the client/server code and repeat the attack in this case. 

Remarks/Hints:
1) Before starting, read about software vulnerabilities and buffer overflows that were presented in class. If you have time, you can also read the classic text on buffer overflows: 
https://www.win.tue.nl/~aeb/linux/hh/phrack/P49-14
and watch videos about shellcodes/exploits, e.g., https://www.youtube.com/watch?v=1S0aBV-Waeo

2) Pay attention to the way the program is translated from the beginning.
It’s better to use compilation flags:
-ggdb -z execstack and -fno-stackprotector 

3) Also avoid Address Space Layout Randomization (ASLR) conditions of local variables by examining and/or writing an appropriate value to the kernel flag (/proc/sys/kernel/randomize_va_space).

4) It is not recommended to change environment variables, e.g., CWD, USER, PATH etc -- can you research why?

