Exploiting is a very interesting topic and there are many ways of manipulating the stack. One of those ways is using the POP, RET functions.
Using the “Free MP3 CD Ripper” - Exploit from my first tutorial, I would like to show how a POP RET is basically working (and displayed in IDA), since these are useful commands if the shellcode is not directly placed @ the ESP, but only some bytes away from it on the stack, like ESP+4 or ESP+8…The modified Python script helps to show how jumping to shellcode via a POP, RET will work:
The .wav gets filled by our usual 4112 bytes of junk first. After that we’ve got the already known position of our EIP, where we’ll fill in a “POP EAX, RET” (opcode: 58 C3 - have a look at the opcode-table at the end of this posting) stolen from the loaded “vorbis.dll”. But what does a “POP EAX” and a “RET” do exactly ? The”POP EAX” takes 4 bytes off the top of the stack and directly stores them into the EAX and “RET” loads the following 4 bytes at ESP into EIP, and therefor gets executed. :-) By the way if the shellcode is 8 bytes away (ESP+8) you simply need to find a “POP, POP, RET” function to jump…
For demonstration purposes, I’ll add another 4 nop-bytes “\x90” after the EIP. Those bytes will be POP’ed to the EAX. The next 4 stack bytes - our already known “JMP ESP” - will used by the RET function. The following 2 nop-bytes and the “\xCC”, which simply breaks the process, will be used to realign the stack. Execute the application, load our new malicious .wav and have a look at the general registers and the stack view now:
The stack view clearly shows you what did happen and what we expected! First: The EIP loaded 0x1BDFEE4 which stores our stolen POP, RET functions from vorbis.dll. Followed by our pseudo-nops “90909090”, which are POP’ed to the EAX using the mentioned function from vorbis.dll. Have a look at the general registers, where you can see that the EAX contains exactly “90909090”. Great! The pop works fine so far. Now the ret gets executed @0x1BDFEEC which contains our stolen “JMP ESP” from “WMVCore.dll”. Then we’ve got some other nops again to realign the Stack (notice that the ESP is @0x1BDFEF0), which means we only need 3 further bytes to point directly to our shellcode. (I’ve just added 2 nops and a break here to break the application flow). In the final version of the exploit simply exchange the “\xCC” with a further nop and the exploit will work again :-).
A nice collection of opcodes: