Answer: The spirit of doing the assignment as a pair is that you work on it together at the same time at the same machine. We do not want people from splitting the project into you do a bunch of problems and I do a bunch of problems because that means the other person does not have the experience of solving half the problems. Also, if you don't know how to solve half the problems, you may encounter difficulties in the final if a similar problem is posed.
Answer: You can try but note that the supplied boxes interacts badly with some 2.6 kernel versions. I've verified that the entire project works on the myth machines and that is what I recommend you use. Also, If you work outside of boxes, you must make sure that the exploits work with the compile toolchain in boxes because that's what I'll be using to grade. No credit will be given for exploits that do not work in the supplied boxes.
"myth10:/tmp/eujin> xterm -e boxes/string &"
I get "DISPLAY not set".
Answer: The following links will be helpful in setting up
your x windows forwarding.
http://www.scs.stanford.edu/05au-cs240c/lab/classmach.html
http://pangea.stanford.edu/computerinfo/unix/xterminal/xclients.html
Answer: Log into the boxes console as root and type "halt". Make sure that nothing important is in /tmp on boxes because that will be wiped clean on startup.
Answer: You could instead put two symbolic links in /tmp that point to both the boxes directory and the cow1 file in your home directory and then run it from /tmp. That way, if myth's /tmp gets wiped out, you only need to reinstate the symbolic links.
Answer: When you put in a get_sp() on your exploit code, it's getting the stack pointer of the main() function in the exploit code. That stack pointer address is based on, among other things, the environment variables in your shell when you executed sploit1. This address might change depending on what you do in the shell beforehand. So basing your exploit code on this address is not a good idea.
But once main() calls execve, the sploit process gets forked and the text, data, bss, and stack of the calling process (sploit) are overwritten by that of the program loaded (target program). Once we're in this state, the addresses that we obtain from running gdb at this point will not change if you don't change the size of the input arguments (i.e. your exploit string length) or the contents of the env pointer argument to execve. That's why you can safely hardcode your address in your exploit code.