sudo yum install glibc.i686If you are using Ubuntu run
sudo apt-get install ia32-libs
Yes, you need the newlines both before and after the "LOL 0wn3d!" message. Of course getting the message in the first place is worth the most points, but the newlines will get you those final few points.
So, an exploit that looks like this:
$ simulate browser < pht24-soln Where to connect? LOL 0wn3d! pht24 is on Facebook! MIPS program exits with status 0 (approx. 8105 instructions in 249071 nsec at 32.32540 MHz)
... is preferable to an exploit that looks like this:
$ simulate browser < pht24-bad Where to connect? LOL 0wn3d! pht24 is on Facebook! MIPS program exits with status 0 (approx. 8105 instructions in 252959 nsec at 32.32040 MHz)
As you may have discovered, you can't simply embed a newline or carriage return in the message, because the browser stops reading when it encounters these characters. Something more clever is called for.
No, a vertical tab is not a newline. You must embed a newline into the message.
The short answer: Use the command simulate -i exploit -d browser
The long answer:
You are likely trying to use one of these two commands:
simulate -d browser < exploit cat exploit | simulate -d browser
This works just fine without the debugger (simulate browser), but what happens when we run it with the debugger? It takes the contents of the file named exploit and pipes that to the standard input of simulate -d browser... but what input does simulate -d browser expect? The debugger is expecting a command from the user (step, continue, info, etc.). Your exploit code is being used as a debugger command, which confuses the debugger and causes it to exit without executing the browser. The -i flag to simulate will solve this problem.
Don't forget that you can find out about the -i flag and other potentially useful flags by running simulate without any arguments.
If you did your work on the CSUG computers, you should submit your binary exploit file by downloading the file directly from CSUG and submitting that file.
Opening up your binary exploit file in a text editor on CSUG, copying what you see, pasting it into a new file on your computer, and then submitting that will not work.
Why is this? Because your binary exploit file almost certainly contains many characters that can't be printed by the editor you used to view the file with. For example, how do you print a null byte? The text editor can't, so it might replace it with a space, or ^@ (the null byte in caret notation). If you copy that directly into a text file into your computer, those characters don't get converted back. You've just completely messed up your exploit file.
The suggested tool for Windows users to use is WinSCP. You give it the same details as you would give PuTTY, and tell it to download your file.
Mac and Linux users should use scp, a command-line tool. Open up a terminal on your own computer (NOT in SSH!!!) and type something like this:
scp NETID@csugXX.csuglab.cornell.edu:lab3/exploit . #The dot at the end of the command is part of the command. Don't omit it!
This says log in as NETID on csugXX, look for the file named lab3/exploit in your home directory, and download it "here" (that's what the dot means). "Here" probably means the home directory on your own computer, and you can figure out what exactly it is with the command "pwd". On Mac OS X, this is probably some directory named /Users/myUsername. There will be a file named exploit in that home directory. Upload that file.
That said, if you were using Linux...
Users of all OSes should also be able to use FileZilla. Set the connection type to SFTP, and use the same hostname/username/password as you would use for SSH.
After uploading your file, you can make absolutely certain it is the exact same file as the one on CSUG by using the md5 sum. Look at the submission screen on CMS. There is a table that will display a string of hexadecimal characters under "md5".
Log into CSUG, and type in this command:
#Assumes your exploit file is named lab3/exploit. #Change lab3/exploit to the correct name if it isn't! md5sum lab3/exploit
It will display a string of hexadecimal characters as well, like this:
63f3dfe77814a22e8f158adbab0a6333 lab3/exploit
If this matches what's on CMS, the file on CMS is exactly the same as the one on the CSUG computers, and you're all done!
If you're sure you downloaded the file from CSUG correctly, and yet the md5 sum isn't matching, we suggest to check whether there's a binary download mode (or something of the sort) in the program you're using to download the file.
There are ways to make your program resistant to changes in stack layout. These clever exploits work when the stack starts in some small region, instead of only working for one fixed location. If you implement such an exploit, feel free to brag about it in your documentation for extra credit!
Finally, there is a way to make your program work with any arbitrary stack layout. We'll leave this one for the adventurous. If you find this exploit, again, specify clearly in your documentation what we need to do to see this awesome exploit in action, and you will be awarded more extra credit.