I tried this one without reading the C code at first, although it should be allowed in the game. This is mainly because I felt like learning assembly the hard way. Also, source codes are not always available in the real world :).
First things first, black box testing. Just send a bunch o A’s. Actually, since 0x41 is A and the buffer is already filled with 0x41, we will send heretic B’s for this evil purpose. From the result we can see the buffer gives us its size. After 24 B’s, the rest is ignored.
Cool, so a 24 bytes buffer. All we got to do is appending 0xdeadbeef to our B’s string. Oh, just remember about x86 being little endian, will you? First problem appears when we realize we must send something in ASCII that will later be converted into hex by the program. So if we literally send 0xdeadbeef, it is going to consider our payload (after B’s) as 0, x, d and a in hex. Not what we want.
Fire up our python interpreter. Just print “\xef\xbe\xad\xde” and see the desired chars to be converted by the program. Instead of inserting them directly, which might not be accepted due to Terminal’s default encoding, let us pipe it with python.
$ python -c 'print "A"\*20 + "\xef\xbe\xad\xde"' | ./narnia0
No errors this time. Also, no shell this time. In fact, there was a shell, but it was closed even before anything could be executed. To keep the shell open, we must use the magical cat - trick. According to man cat:
With no FILE, or when FILE is -, read standard input.
So cat - reads stdin, which in our case is the program output, printing it gracefully for our pleasure. Just a final trick, in order to pipe multiple commands stdouts, just put them together inside parenthesis.
Final command is:
| $ (python -c ‘print “A”*20 + “\xef\xbe\xad\xde”’; cat -) | ./narnia0 |
I expect to analyse the assembly code line by line soon.
