As you should be able to tell from the disassembled code for browser, the SYSCALL instruction works pretty much just like a regular function call. The only difference is that before invoking, $v0 must contain a numeric code for which operating system service should be invoked: 1 for "printi", 2 for "prints", 3 for "putc", and so on. These numeric codes are not standard, but are specific to the cs3410 simulator. Other simulators you might find on the web will use their own numeric codes.
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 make the difference between a 9 and a 10, say.
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.
Standard convention is for main(int argc, char **argv) to be invoked with the name of the program itself as argv[0]. In order to support this, the simulator pushes the name of the MIPS program file on to the stack before invoking main. You may have noticed this file name appears near the top of the stack.
Important: An unfortunate consequence is that the stack alignment of main and all other functions depends on how you invoke the program. There are ways to avoid this.
Option 1: Always be sure to invoke the simulator using the exact same file name argument for the browser file. In other words, whatever you are using as the last argument to the simulate program, you should always use as the last argument.
So if you invoke the simulator like this:
$ simulate ./browser
Then any of these is acceptable as well, and will not change the stack alignment:
$ /courses/cs3410/sim/bin/simulate ./browser $ simulate -d ./browser $ /courses/cs3410/sim/bin/simulate -d -i exploit.binary ./browser $ cat exploit.txt | xxd -r | simulate ./browser
But any of these will cause the stack to have a different alignment:
$ simulate browser $ simulate /courses/cs3410/hw3/browser $ simulate ~/browser $ simulate hw3/browser
Option 2: Use the "-noargs" option of the simulator which will always invoke main with some constant-length arguments regardless of what you write on the command line. Using the "-noargs" option, you can invoke simulator any way you like and it will always use the same stack layout:
$ simulate -noargs browser $ simulate -noargs ./browser $ simulate -noargs ~/browser $ simulate -noargs /courses/cs3410/hw3/browser
Although this is how real programs do work, this extra wrinkle in the assignment isn't intended to add extra difficulty to it. You may specify in your documentation what path to browser is appropriate for your solution, and we will honor it when testing.
Without any specification, we will assume that "browser" was used, or that the "-noargs" flag was used. You should prefer one of these two options unless you have already tested extensively with another option.
Also, 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!
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.